3 ms·
I have learned all the frontend frameworks (though my React is pretty shitty) and have come to the conclusion that I much prefer just rendering HTML with html/t
by jrockway 4y ago
I have learned all the frontend frameworks (though my React is pretty shitty) and have come to the conclusion that I much prefer just rendering HTML with html/template.
The thing that led me to using the SSA style initially was that it seemed easy to write a backend and then bolt on a frontend. But there isn't actually a good transport layer for that, and the API for your web app and the API for API users usually end up being quite different. I think that GraphQL is intending to be the transport layer that just works (and since it's a graph you can query, theoretically means you don't have to write an API for your web app, teach your web app how to incrementally request things, cache things, invalidate that cache, etc.). I have found that ... it's not that great. The Go libraries for a server are terrible. There are no debugging tools. You send gigabytes of JSON for no reason.
My personal favorite API is gRPC-Web, but I guess browsers never added the hooks necessary for bidi streaming, and the "tree shaken" protos + gRPC-Web runtime are HUGE, so I've decided it's not worth being excited about anymore. I typically stick grpc-gateway in front of my gRPC services and get normal RESTful JSON. And then I'm at square one where there isn't any magic in React to make that particularly useful.
Anyway, yeah... just printing out HTML. Not that bad. Use fly.io and put the server close to your user and they won't even notice that it's slightly higher latency than caching everything in your SPA. And it sure is easy to debug when something goes wrong.
- Existenceblinks 4y agoThe tricky part of edge compute though is write operation and where the data store is.
- eurasiantiger 4y agoNever roll your own GraphQL server on core libraries. There are existing implementations with good practices and debugging tools.