[Meta] Tachidesk-Server 1.x

[AriaMoradi]

There are some early design decisions in the app that we can't change or is too complex or too substantial/fundamental to change with smaller incremental patches; Having these changes would call for a "rework" of the app.

Also as a desktop and (self-hosted) server application, Tachidesk is not just merely a remake of Tachiyomi anymore, it's a different solution to different problems and needs, so we should create a new vison as the only common ground we really have with Tachiyomi is support for its Extensions and backups.

The changes are up for debate.

Changes in the organization

• Drop the name Tachidesk, rebrand as Suwayomi and Suwayomi-Xxx completely

Changes for Tachidesk-Server 1.x

• Changes in API system
  • Move from REST API to GrapghQL, remove Javalin (Supported by @martinek and @Syer10)
  • Support both REST and GraphQL?
  • Support for proper Authorization and Authentication
  • Better Error and request result reporting (+ l10n and i18n)
• Database and data model changes
  • Support for multi-user
  • Hot-Changeable settings, move away from com.typesafe.config
  • Change ORM: Expoed has worked for us so far but if we are going do redo the database structure why not?
  • Allow the user to use PostgreSQL instead of H2 for better performance
• Support for more Komga-like features
  • Better Local Manga Source (or a separate system)
  • Allow for loading and saving manga
  • Change the terminology: Book instead of Manga or Entry
• Misc.
  • Rename the base package from suwayomi.tachidesk to org.suwayomi

Changes for Tachidesk-WebUI

• Desktop client via ElectronJS or Tauri
  • Use desktop features: Notifications
  • Cloudflare bypass solution
• WebView based Android client (ref: super-productivity-android)
  • Notification support
  • Cloudflare bypass solution
  • Image caching
• iOS client
  • ???

[Syer10]

Move from REST API to GraphQL

GraphQL is a powerful way query a website, it allows many different queries, with support for filtering, paging, and a bunch of other things. GraphQL allows you to build database-like queries with all the data at your fingertips, performantly.

remove Javalin

50/50 for me, Javalin supports everything we need on the graphql side, and it would support JWT authorization, but so would Ktor which is what I would prefer.

Support both REST and GraphQL?

I think it might be good to have both for a while, maybe permanently move to GraphQL once its battle tested.

Support for proper Authorization and Authentication

JWTs would be perfect for this, JavaLin and most other frameworks support JWT since its a very common way to handle login.

Support for multi-user

This could be easily possible with minimal changes. With JWTs we could have a way to map between tokens and user ids, and with GraphQL we can make all queries internally use it with minimal changes.
With the Manga table we could split out user data like 'inLibrary' into a separate table and store it with a user id, and do the same with other tables like Chapters. With meta tables we can add a userId column, same with Categories and such.

Hot-Changeable settings, move away from com.typesafe.config

100% support this, we could still temporarily support the old format, just remove the library and use Kotlinx Hocon Serialization to read it.

Change ORM: Expoed has worked for us so far but if we are going do redo the database structure why not?

I would keep it since I use it for GraphQL quite a lot, it allows you to build queries in code, making it perfect for use with GraphQL.
If we only used the REST api I would suggest SQLDelight, but it would work horribly with GraphQL since all queries need to be pre-made.

Change the database: write to sqlite without race conditions or keep H2

100% Keep H2, its one of the best databases for GraphQL.
Its the best database to use in this situation since we need to allow users to run the application without setting up an external database.
SQLite doesn't have all the features needed to support everything GraphQL is made for. One example would be string queries, every string query thats case insensitive would need to be make every row in the column lowercase before comparing, massively reducing the performance of string queries.
The only database I know of that has better support for GraphQL is PostgreSQL, MySQL seems to have the same amount of support for GraphQL as H2, but both those databases need to be run separately.

Support for more Komga-like features

Never used Komga, but would probably be a good idea to take inspiration from them

Better Local Manga Source (or a separate system)

I think we could make local source automatically in the library, either through a file watch on the local source folder or checking if there are new manga when the default category is fetched

Allow for loading and saving manga

Exporting manga to a format like ComicInfo would be a good idea, it would allow users to store their data without any changes from the source to propagate.

Change the terminology: Book instead of Manga or Entry

I prefer entry, since Tachidesk can be used for non-books as well since its just images.

[doctorniz]

I am not a manga/manhwa reader currently but would like to get into in the future. I look primarily for ease of use to read comics. I have my own library, primarily in cbr or cbz form. There is a huge gap in the market that this software in particular fulfils for myself that the current conventional setup in the comic world does not meet. There are a few caveats too.
I run everything dockerized and headless, so I am unable to use fmd2 or hakuneko for downloading. I installed lanraragi but the ease of use was something lacking.
I tried the "gold standard" comic downloading set ups of mylar3 and lazylibrarian but they work on torrents and newsgroups and are primarily for automatic downloading of comics/manga as they are released.
I used kavita as a web reader but I just spun that container down just now as well. I use the paperback app on ios with tachidesk extension to connect on and the tachij2k app on android and connect to tachidesk as my only extension. On the tachi-server, I am able to control which sources I use which include local (pointing to my existing library of comics) and a few other comic ones.

What I am trying to get at, is that the potential is huge.
What I feel is missing is (for my use case)

• ability to reliably download cbz files (the preview version did not fix the issue)
• ability to read cbr files without crashing
• add appropriate metadata in the form of a ComicInfo.xml file/fetch metadata given scrapers/APIs
• rename file upon download/move files from download to local once done
• automatically download latest chapter as it is released
• integration with a reader like Komga or Kavita for reading

The name change is understandable - I can see the friction in some other posts
GraphQL seems sensible, but I think supporting REST for now also seems reasonable
Multi-user seems great

Shame that this might break the Paperback extension, but I am sure a better solution will arise.

[taos15]

Change databse

The ability to switch databases to something like postgres good but I domt know the postgres graphql support.

Name change

Name change seen appropriate.