this post was submitted on 08 Oct 2024
28 points (96.7% liked)

Programming

17666 readers
343 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
28
How to ensure my web app has backward compatibility with importing JSON based user data? (lemm.ee)
submitted 2 months ago by [email protected] to c/[email protected]
16 comments fedilink hide all child comments
 

I am working on a small web app that stores user data locally using indexedDB which can be imported/exported by making use of JSON files. Since I plan on adding updates to the site, I want to know what best practices I should follow to make sure my app can allow importing of user data from older versions. It could be related to how I should define the properties of my user data object to make it future proof, or any library or tool I could implement that would make this migration process easier.

Do keep these points in mind:

  1. I am using NextJS to build this application and Dexie to manage indexedDB
  2. Without going into details, the user data file makes use of heavily nested objects and arrays and most likely won't fit in a cookie or even in the local storage API
  3. This web app acts as a proof of concept which must only make use of the aforementioned core technologies, regardless of whether more efficient alternatives exist or not.
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 2 months ago (2 children)

Obligatory "JSON APIs are not REST because JSON is not hypermedia".

GraphQL is a mess too as you throw out any ability to reason about query performance and it still requires thick clients with complicated/duplicated business logic.

If you're doing RoR anyway, then go for https://htmx.org/. It's much, much simpler and closer to how the web was originally designed. Highly recommend this book the author wrote on the subject (also provides tutorials walking through building an app): https://hypermedia.systems/book/contents/.

[–] [email protected] 2 points 2 months ago (1 children)

HTMX is great by I don't think it's what OP needs since the input and desired output is not hypermedia in the first place.

[–] [email protected] 2 points 2 months ago (1 children)

I was replying to someone talking about GraphQL and Ruby on rails, not the OP of this post.

[–] [email protected] 1 points 2 months ago

No but you are misunderstanding me — I’m talking about a web API for others to consume, not using GraphQL in the frontend of a website.

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago) (1 children)

I’ll give that a look, thanks!

Edit: This looks like a JavaScript library rather than a serious API standard.

[–] [email protected] 1 points 2 months ago (1 children)

I don't know what you mean by an API standard, but yes, it is technically a JavaScript library. But that's only an implementation detail and the spirit of htmx is that you write very little JavaScript. Javascript is simply used to extend the HTML standard to support the full concept of hypermedia for interactive applications. An htmx-driven application embraces hypertext as the engine of application state, rather than the common thick client SPAs hitting data APIs. In such a model, clients are truly thin clients and very little logic of their own. Instead, view logic is driven by the server. It has been around for quite a long time and is very mature.

It's fundamentally different than most JavaScript libraries out there, which are focused on thick clients by and large.

[–] [email protected] 1 points 2 months ago (1 children)

I’m discussing APIs that can be consumed by others, not something for my frontend to use.

My frontend uses Hotwire — I’m not using GraphQL as some Node.js guy writing the entire frontend in JavaScript.

I think you’re discussing PWA technologies where I’m trying to talk about web APIs.

[–] [email protected] 2 points 2 months ago (1 children)

Ah I see, my bad. You mentioned Ruby on rails and GraphQL so I assumed you were talking about some kind of MPA situation.

Yeah htmx doesn't replace data APIs for sure. Still not a fan of GraphQL for that purpose for the reasons above. There's a lot of good options for RPC stuff, or even better, you can use message queues. GraphQL is just a bad idea for production systems, IMO.

[–] [email protected] 1 points 2 months ago (1 children)

Yeah everyone says this then I look around at REST APIs (as a consumer and developer) and 99% are trash.

I’m loving GraphQL mainly for “take only what you need” and type definitions. Every other standard I can find has some crummy gem, serializers that need to be hacked because they never work out of the box, etc.

As soon as my experience changes maybe I’ll change my mind, but I’ve had to develop some REST APIs using Ruby and Rails and wasn’t happy. Meanwhile my side projects using GraphQL are just incredible, and I don’t want to kill myself after developing it.

[–] [email protected] 1 points 2 months ago

I wasn't suggesting making JSON "REST" APIs (not actually REST, more accurately you might call them JSON data APIs or something). I meant protocols that are specifically meant for RPC, like gRPC, JSON-RPC, etc. Or message queues like RabbitMQ.