I logged how many hours I’ve spent so far on this and it’s130 hours (±10)
During that timespan I also implemented a test framework for Lamdera (20 hours)
Basically avh4/elm-program-test but it simulates multiple frontends and the backend.
This turned out to be a good time investment as it allowed me to simulate some time consuming user interactions without having to test it by hand before every deploy.
Lastly, thanks to @supermario for helping me set up email notifications and making the UI look better.
I started to read a bit its code but I haven’t found the app entry point. Where is that?
I was also wondering what src/Evergreen was? I’ve seen in the commit history that it has to do something with migrations but I haven’t found any information about such a package online nor any references to it in the rest of the code base.
The backend does run on a single thread so there’s potential for a bottleneck there (hopefully that can be improved in future Lamdera releases). In order to address that, I’ve thought about how I can make it so fewer requests need to be sent and how to make requests smaller.
In a lot of systems, efficiency is given up for the sake of making it easier to program. Some examples are:
Frontend polling rather than having the backend keep track of subscriptions and pushing updates
Having “uber-endpoints” that give you all the data even though most of it won’t be needed
Requesting data on every page load rather than caching it locally and using that if it’s not out of date
Needing to make multiple requests chained together rather than having one request that gets all the data immediately
When the frontend creates an object on the backend, the response contains that entire object even though the data needed to create it already existed on the frontend
Since I’m writing Elm on the frontend and backend, a lot of these complexity vs performance tradeoffs can be avoided, and so Meetdown gets to be more efficient with the CPU resources it does have. Still, Meetdown is guilty of some complexity tradeoffs and I’ve been experimenting with how to address them.
I haven’t done any stress testing so I don’t have a good idea of how many people need to use it before there are scaling issues. My vague guess is it’s in the 100,000+ user range (in part because users don’t need to interact much with the site, they just join an event and wait).
There are two entry points, the frontend one is Frontend.app and the backend one is Backend.app (Lamdera uses app instead of main as its entry point keyword).
src/Evergreen contains modules Lamdera has generated in order to facilitate type-safe migrations if I made a breaking change in the Frontend/Backend model or msgs. You can read more about it here https://dashboard.lamdera.app/docs/evergreen
For the time being Lamdera doesn’t support meta tags or SSR so there isn’t much I can do within the app to improve SEO. Hopefully these feature will get added but I don’t think this is a big problem for the time being. I think most people are going to find Meetdown by seeing a link to it here, on Twitter, or on Slack.
That said, Meetdown still managed to be the 2nd search result on DuckDuckGo (it’s nowhere to be seen in the Google search results though)
This is awesome. I’m now ready to close my own thing and use this for our Elm/Haskell meet-ups!
One request for improvement: I couldn’t log in via my phone, since the link from email is opened in a browser window that has cookies different from Safari (on iPhone), so you end up logged in in a webview but not in a browser. Switching to some one-time code, or adding a token that logs you in one more time if you press “open web browser” would help.
Thanks! I’ve gotten feedback from other people as well that the login flow can be difficult if you’re on multiple devices. A one-time code might be a good solution. Another idea is to implement oauth. The are many options and I have a bit of analysis paralysis now
By this you mean, a button is shown to the user after they click on the login link that lets them login the device that had originally requested the login? If yes, this is something I’ve considered, but I’m a little worried that a hacker might trigger login requests for a bunch of email addresses and hope that someone clicks on that button without fully understanding the consequences.
I just mean this button on bottom right that iOS gives you that essentially means “open current page in actual Safari”.
If this specific page only would have a URL that would look like “…/successful-login.html?onetime-token=12355”, it could allow that token to log user in once, thus opening in your iOS Safari would just do another login, which could work.
While oAuth login is great, current email based login will still be confusing if not fixed (or disabled completely), so it’s a problem that needs to be fixed IMO.
