For the lols I put together an alternative implementation of the Realworld example app - with a graphql backend and frontend with Elm UI.
The frontend is a grab bag of various patterns and techniques I’ve been playing with recently
The backend uses Hasura (a graphql api over postgres) and a Kotlin http api (using http4k)
The infrastructure (most of it) is deployed using terraform
Experience report
Obvs I found Elm a pleasant and relaxing experience (no surprises there!). Elm graphql + Elm UI are a dream stack to work with
It was remarkable how little time I spent on the backend (and how little code there is for it). If you haven’t tried it I would thoroughly recommend trying Hasura out. It felt like a really nice balance between very powerful out of the box features and the ability to extend and customise using other applications and services
Kotlin is nice (have been using it at work) - the server functions as an extension to Hasura (handles authentication and some more detailed logic). I’d quite like to try and rewrite this in purescript however to see if I can have a mostly serverless stack (I tried deploying the kotlin api on AWS lambda and it was horribly slow)
If you would like to do a serverless stack in a functional programming language, I made a start at doing one in Elm:
Its called ‘fullstack’ because the plan was to write a back-end in Elm and then deploy that together with the existing Elm front end to yield a 100% Elm realworld implementation. So far, I mocked up the API end points using elm-serverless. Then I started thinking about what to do for a database, and got distracted generating AWS service stubs for Elm with a view to being able to use DynamoDB more easily from within Elm.
If you’ve already got the database and a graphql API, that would remove the need for DynamoDB, so I think it could be easily achievable in Elm.
Awesome work, but it might be confusing to name this realworld? As my understanding was, that there is a specification for both frontend and backend, and that spec is REST. Or did you trim your graphql queries to conform to this?
Thanks! Yea I was thinking about this, there is a specification REST + the frontend css, they’ve also added a section for fullstack implementations that don’t necessarily follow the original spec but “adhere to the same functionality & UX specs.”
Do you have any thoughts on a name that might be clearer?
I was pleasantly surprised to learn that they now have a Fullstack section:
Since these implementations are responsible for the entire stack, they obviously cannot be mixed and matched but they still adhere to the same functionality & UX specs.
Hey Andrew, nice idea to do the realworld project with elm-graphql! That’s an awesome resource to have, thanks for taking the time to put that together.
I hope you don’t mind if I make a couple of small suggestions. In particular, Scalar codecs is one of one of my favorite features of elm-graphql, because with Elm types you can really leverage GraphQL Custom Scalars in a way that you can’t in many other languages. So there are a couple of places where you could consider using that feature.
For example, the timestamps could use scalar codecs:
I really like encapsulating things with custom scalars as much as possible. Another example of a place to use a Custom Scalar is for a profile image. You could consider defining an Avatar custom scalar type in the GraphQL schema. Then you could expose a codec in that module and make the Avatar type opaque, so the only way to build or use that type is defined within that function. That way, you can’t accidentally pass another type of String to be displayed as an avatar, and you also have a clear responsibility of displaying avatars that’s narrowed down to that one module.
Hope those suggestions are okay! Very nice to see a large example, thanks again for putting that together. I’d be happy to discuss more if you’re interested, feel free to ping me on Slack!