artellectual
Joined 15 years ago
Joined 15 years ago
Also the fact that you have to setup API endpoints for your data, with liveview, you have direct access to the data. You can load any state with a function call instead of having to develop a separate endpoint for your frontend, handle hydration etc... You need real-time updates? It's done out of the box, you don't have to think about it. With react, that stuff is just ALOT to do.
I ended up removing a lot of controllers from my codebase that was there just to service the react front-end. Having those controllers do not service as the "API" of the app. Specs for front-end apis and core APIs are usually quite different based on my experience.
The easiest way I can explain it is LiveView is the least friction between thought and output. React / TypeScript just gets in the way because of all the choice and abstractions you have to build for it.
Don't get me wrong, React still has it's place, there are things I would still use react for, like if I need to render something visually rich, like a flow diagram (reactflow.dev), or video component, or make something like Figma, or a calendar / gantt chart, but for most front-end UIs (95%) you just don't need React.
The main reason for that is, the LiveView test framework is super simple to work with. I didn't write any tests when I was doing React / TypeScript just because it seemed so cumbersome to setup. Having a test suite that works out of the box made me write more tests for my front-end.
Not having to build API endpoints for my react components is also a huge accelerator in productivity.
In the end I ended up writing less code, with more polished / well tested front-end.
You can watch the video of what I built with LiveView here https://instellar.app
Thank you for your feedback.
For error handling when the task fails it sends a message to the genserver we can also use that opportunity to handle retry, or do a strategy change where after first failure we throw it into a job queue.
This way we optimize for user experience and at the same time have a robust strategy for handling failure. I guess that can be another blog post on its own.
Once it's delivered the entire runtime / lifecycle / upgrading / bootstrapping is managed by LXD/LXC containers.
It's definitely possible to open up PAKman's support for other build environments. I mean at the end of the day it's just an alpine linux package. As long as you can use alpine's package manager it should work.
https://instellar.app can also serve as a repository for your package. This was an option we considered to enable earlier, but figured people might just want a fully integrated solution.
In this post I show you how our product instellar.app handles multi cloud deployments. Instellar also makes it easy for you to manage multiple installations of your apps.
Installations basically turn your single tenant app into a multi-tenant app without having to manually code your app to support multi-tenancy.
We also give you a sneak preview of some of the work going into making Rails and Python based Apps compatible with Instellar.app!
Hope you like it!
If there anything else that I've not covered please let me know. Would greatly appreciate the feedback.
It does load balancing / automatic ssl issuing out of the box. It will also allow you to scale horizontally. I’m working towards making it public soon.