I made a meetup.com clone

There’s this website called Meetup that lets you find groups of people that share some interest and meet up with them.

I don’t like it though, the website feels bloated, they charge money, and worst of all it’s probably not written in Elm.

So I decided to try out making my own version using Elm + Lamdera. It’s called Meetdown and here’s the result! Also here’s the source code.

Here are some screenshots of the app in action.

Some interesting trivia:

  • 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.


Awesome. Kudos to the creators :+1:

1 Like

This is really nice!! I’ll keep it in mind if I ever need to run some sort of meetup and I’ve starred the source code for study later. Thank you!!!


Yes, the worst thing about MeetUp is that it is not written in Elm. Has to be. :smile:

Well done, Martin.


This is awesome!

Btw, have you considered how well it will scale on Lamdera if it gets popular?

Looks interesting!

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

1 Like

Thanks @MartinS for the response. Apparently I need to read more about Lamdera, it sounds very exciting.

1 Like

Thanks for the thorough reply, it’s quite interesting to see your rationale!

If I can ask something else, how have you accounted for indexing via search engines? Is there any SSR involved?

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)

I wonder if the card’s complete lack of useful information and just repeating “meetdown.app” 3 times makes it more eye-catching :thinking:

Edit: I checked again now, DDG no longer shows Meetdown in its search results

1 Like

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.

Thank you!


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 :sweat_smile:

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.


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.