I posted an earlier question about caching and prefetching. Since then I have continued to ponder ways to implement less boilerplate in a large CRUD app, ignoring the question of optimizing page loads.
For the following hypothetical scenario:
3 developers in series A startup with ambitious roadmap
python flask + sqlalchemy backend
My dream architecture might follow NRI’s old style:
server side routing, one elm app per page - avoid implementing a REST or graphql API (at the cost of having some small flicker when a page changes, and some boilerplate initializing an elm app in each page)
Originally, I was thinking of something like remix or elm-pages-v3 to avoid the API, but I don’t think I would need to optimize page loading while still trying to determine what features to build.
When you say this, what do you mean? I.e. do you have physical limitations to typing, do you struggle to read lots of code, do you just dislike writing lots of code, something else I’m not thinking of or unaware of?
My 2 cents
Tldr: boilerplate feels like misdirection for me because it’s never been easier to write & read code than it is today.
I’ve written a fair amount of Rails which is very much on the lower end of boilerplate, and even more Elm which is on the high end. Elm requires significantly more text, but I use autocomplete, Codepilot, elm-codegen, elm-review, and more to reduce the quantity of actual typing I do. For every 1k lines of Elm I “write” I’m probably only typing 200-400 lines of actual text.
I can’t speak to physical challenges like carpal tunnel, but these same types of tools also help here. There are also a growing number of tools for speech-to-text that help with this. I worked a job in college that was to do speech-to-text and the technology has significantly improved since then.
As for reading, Copilot and similar tooling is growing a lot here right now. I can’t yet speak to the use of these first hand, though I have heard coworkers who are loving tools that generate a synopsis.
dream architecture
IMO there is no single dream architecture as every project has different needs. What are you trying to build? What are your needs? What are your users’ needs? What are your limitations? Where are you willing to compromise?
I think this can be a good way to start, in the sense that breaking apart a monolithic single page app is much harder than combining lots of individual pages together into a single page app - provided you have some consistency over how you implement the individual pages that is.
You can mix and match with server side rendering tech that you are used to, such as python flask. That should help you quickly create the more static parts of your app, and the more interactive parts can be done in Elm.
It’s the mental overhead of maintaining the API. How should it be organized and where should I place my new type within the existing API? Should I add tests covering the graphql/rest api layer or not? integrating a codegen library for serializing/deserializing entity types that flow through the API into the overall build. These all feel like distractions that I am doing to follow a standard SPA + backend for front end API pattern. Boilerplate might be the wrong word. Maybe bureaucracy?
Oh! That’s makes a lot of sense. @RyanNHG talked about this in the most recent episode of Software Unscripted and was an inspiration for him building Elm Land.
I’d say elm-pages also fits this need for people who are trying to build static or semi-statislc apps.
I’d definitely recommend checking out Elm Land though. Ryan is working hard to provide an opinionated framework for people to build apps with Elm. I’d think of it like Angular or Ember for JS, where the whole setup is there for you and you focus on just building your app.
elm-pages v2 and the pre-rendered routes in v3 are built for handling static/semi-static routes.
Server-rendered routes in v3 are designed for use cases with dynamic user data with features like cookie-based sessions, the Form API (and in-flight submission state), etc.
It uses the same strategy that the NoRedInk rails rendered routes use, except it’s built-in to the framework to reduce glue code because you’re working in full-stack Elm (so no need to write an API layer because you can directly get your initial page data, and subsequent data submissions and data loads by responding form submissions with no API layer as well).
For example, here’s a demo of a CRUD admin panel app. This page lets you create/update blog posts directly in Postgres without going through an API layer.
For updating existing posts, it gets the initial data here:
This example uses Prisma, but it can run any Node code for the BackendTask.Custom.run handler.
I think elm-pages-v3 (might want to name it isomorphic-elm-land or something to reduce the general confusion about static sites only) is a great option for teams close to product market fit or mature applications. It feels like initial server render combined with client side hydrate is overkill for prototypes and searching for product market fit phases.
For a mature product, my only hesitation about elm-pages-v3 would committing to the node ecosystem for my backend. I understand that choosing node as the default backend implementation is very convenient for invoking elm render and is a good MVP choice for elm-pages-v3. I also understand that elm-pages-v3 could eventually document how to implement alternative backends using any language ecosystem.