The intention is to use modern technology (GraphQL, Elm!, HTTP/2, SSE) to avoid heavy reliance on a traditional web backend (node, express, etc), simplify implementation and create a types-without-borders pipeline from UI to DB.
Does elm/http support HTTP/2 and will it support HTTP/3 ?
Does elm/http support SSE?
If not, how would we implement HTTP2/3 + SSE in Elm?
What would be the best way to hydrate the elm UI into browsers or into a PWA?
The PWA is to help field technicians capture all types of tasks on to a phone or laptop. The technicians work in data centers and each task has a start and a stop time, data center location, date, categories and comments.
There are two options for hosting the PWA:
somewhat self-managed infrastructure like Digital Ocean with Hasura GraphQL
fully serverless infrastructure that may or may not give me the stack I want (maybe no Hasura).
if somewhat self-managed infrastructure:
Hasura can be used as the GraphQL endpoint with Postgres database underneath.
Authentication and authorization can be handled by Hasura and brokered by Auth0 (all users have Google accounts created for them and will authenticate with those).
All routing is done by Elm and nothing on the server other than for hydration.
Once hydrated (PWA installed on mobile or cached in browser) only updates will be required.
Not sure about interactive file uploads, or serving images or svg elements used in the UI. Field techs need to upload images taken of receipts.
General questions about hosting and architecture. The goal is to keep it as simple as possible. The app will be mostly rendered HTML and CSS (via elm-ui):
Do I just need to run something like NGINX as web server?
Should I think of serving to a PWA as being just like serving to a website except much lighter weight on the backend? This is a question about infrastructure and pipeline complexity.
Should I consider choosing a serverless provider that offers Hasura, HTTP2/3, SSE, web serving and CDN?
Dillon Kearns’ Elm Pages seems like it could solve a lot of challenges. Maybe combining:
elm-pages
elm-ui
elm-graphql
Hosting the app on Netlify and the Hasura endpoint on either Digital Ocean or Heroku. Authentication could likely also be provided by Netlify. Unfortunately still no Hasura hosting on Netlify.
It looks like HTTP/2 will be used by modern browsers if the server supports it. So Elm doesn’t need to even know about it.
SSE-over-HTTP/2 looks like it would be a good fit for Elm and for PWAs in general as it is HTTP-infrastructure and CDN friendly, unlike Websockets. And as you say it might be simple to connect to from Elm. Maybe just pointing elm-graphql subscriptions to EventSource through a Port is all that would be required?
HTTP/2 Server Push exists but there doesn’t seem to be any way to connect to that directly from Elm. I am curious to know if HTTP/3 will have something like SSE built in.
Regarding the PWA do you intend to use ServiceWorkers to intercept and perform actions on HTTP requests (i.e. offline support)?
If yes, you should be aware that elm/http under the hood uses XMLHttpRequest and not the fetch api and all PWA ServiceWorker functionality that intercepts requests only work with the fetch api.
I know of no really palatable ways to deal with this if you want to do a PWA with Elm.
Two suggestions I’ve seen are 1) Monkeypatch XMLHttpRequest to use Fetch 2) Run all of your requests through Ports. Neither of these suggestions are very inspiring.
Hopefully I’m wrong or somebody can chime in with better idea.
Okay so it looks like I’ve been proven dead wrong about the assertion that PWA can only work with Fetch API. I’m the one that’s been spreading the news that you can’t do ServiceWorker interceprtions without Fetch. Looks like I’m wrong.
I stand corrected, ignore my previous statement and carry on with your PWA planning.
I’ve been thinking about PWAs and SPAs and both names feel inadequate for describing a modern web application built in Elm, which really wants to be the best of both.
It would be good if the Elm community could come up with a singular name that describes the foundation for:
SPAs
PWAs
websites
static site generators
Maybe they would really just turn out to be mostly identical except for some part of the design that calls for a very specific use case.
For example, both an SPA and PWA follow Elm’s single page design, which appears to be a byproduct of TEA.
Likewise, a website and static site generator (like Elm Pages) are single pages. One pre-renders all of the static content but that is still added as a performance enhancement to a single page design.
Both would benefit from offline caching via ServiceWorkers (not sure how images are cached). As would SPAs and PWAs. All of the above benefit from using HTTP-compatible technology, like HTTP/2 + SSE instead of Websockets. HTTP/3 is just around the corner.
Elm SPAs, websites and static site generators are starting to look like fundamentally the same thing. They could all be called Progressive Web Apps.
Correct me if I’m wrong but as PWAs goal is native-like experience they imply offline persistence, and eventually push notifications and other native features, unlike SPAs. In that sense PWAs are a subset of SPAs.
By the way I’m building a serverless Elm PWA using Firebase for hosting and functions, Firestore as a database with offline capabilities, and Workbox for the service worker. Elm ports are a great fit to communicate via messages with the web worker in charge of the Firestore database layer (that is using HTTP/2 under the hood).
@nickwalt the main advantage (and the main drawback) of Elm is its strict separation from the JavaScript parts, so in my case “integrating” Elm with Firebase was essentially using Elm for the UI in the main thread and communicating with a web worker dedicated to Firebase features (Auth + Firestore). Offline persistence with web workers is still an experimental Firestore feature (see issue here). Firebase usage is way easier if performance is not an issue and you simply use Firebase CDNs (Firebase is bulky).
Also you were talking about using PostgreSQL, so be aware that Firestore is a no-SQL database, it might not suit your purposes the same way a relational database would…