Rather than getting stuck on an app idea itself, I’ve been in the habit of rebuilding my own personal website jackmarchant.com in different languages, different technologies but for the most part it’s the same outcome.
Sometimes it gets a bit boring to build the same thing again, but it allows me to focus on the technology I’m trying to learn or become more familiar with. It’s a pretty simple website, I’ve never strayed too far from having a blog, maybe some extra content here and there or fancy front end features.
I’ve built jackmarchant.com with:
- S3 Bucket serving a single HTML file via Cloudfront
- Silverstripe CMS and framework
- Ruby on Rails
- Node (Express)
- MeteorJS and React
- Elixir GraphQL API with React and Relay on the Front-end
- And most recently, a Phoenix application, the web framework for Elixir.
I put together a few goals this time, which is very rare for me because usually I'd be happy to put something together quickly and get it out there.
- Enable and encourage myself to write more
- Make it easy and blazing fast to publish
- Support markdown to make it easier to cross-post.
- Enable further engagement between my articles and readers (using something like a subscribe form - spoiler: it IS a subscribe form)
- Build for mobile first. Mobile is where I do a lot of reading, so I appreciate other websites that make that experience great.
Given the goals I set out, I’ll give you a breakdown of how I built this app:
The majority of these websites were deployed on Heroku, which is good for exactly deploying small apps quickly (and not a whole lot more).
Fortunately, I’ve had lots of practice rebuilding it so it was quite easy to repurpose an existing Heroku application with Elixir and Phoenix build packs, copy over some config and make some updates so that Phoenix can connect to a Postgres database.
I created a new Phoenix application, and left a lot of the defaults in place, as I wanted to see what the developer experience is like with Phoenix. Turns out it’s really good, and encourages a lot of good practices, such as built in support for CSRF tokens in form post requests, organising application domain logic, interacting with a database and so on.
The Phoenix documentation talk a lot about what they recommend in terms of structuring based on Contexts, but ultimately it’s still flexible enough for you to do whatever you like.
I created a simple Task which would run once when the application starts. This would translate my markdown posts into HTML so they can be presented on the page.
I wanted to get out of my own way when writing, and a way to get my markdown files shown on the page in the simplest way. So this Task called PostReader scans a folder for markdown files whenever the application starts, read their contents and metadata, before translating it to HTML through an Elixir library called Earmark.
I then upsert (insert or update) to the database with the HTML and that’s what gets shown on the page. Upserting allows me to make changes to existing markdown files and have it update on the website.
This is perhaps the least amount of time I’ve spent on the front end, as I wanted to basically have enough there that it looked nice enough, but more importantly that the articles were readable and code examples were clearly displayed.
With code reloading standard in Phoenix, quick changes and updates were a breeze.
There’s nothing complicated about the front end, although it gave me a chance to use EEx (Elixir compiled templates) more thoroughly where typically I’d reach for React.
The subscribe form takes an email address and creates a new subscriber record in the database. I will be using Heroku’s data clips to maintain a record of subscribers and as volume increases I may upgrade this to integrate with a third-party email provider. Oh, by the way enter your email address and hit the button and I will grant you three wishes.
What did I learn this time?
- I should decide on a few high-level goals before starting on a project, otherwise it can feel like you're never really "done". I learn best when I have to try to explain things to someone else, so I find writing is a way for me to do that. So, hopefully I will learn that it's better to spend more time writing and less time rebuilding my website over and over again!
- I learned to appreciate not overcomplicating things and to keep is simple, sultan.
- I learned to focus on what matters most on the web, the user experience.
- I realised I need to find another hobby on the weekend.
Top comments (5)
How does making a Phoenix app with eex templates compare with Absinthe+React? graphql/absinthe looks great but concerned about not-so-obvious pitfalls.
I think they’re for different use-cases. If you’re building a web app with lots of interactivity then it makes sense to defer some responsibility to the client, but in my case I have a list of posts and no need for JS, so when I built the same thing with React and graphql previously it was much more complicated.
That said I use React and Absinthe a lot in my day to day work, and I know there’s some difficulties in using Absinthe before you’re familiar with it. The creators released a book recently: pragprog.com/book/wwgraphql/craft-...
I was thinking starting out with Eex and then once there are more interactive needs, add Vue.js to the stack. Elm or React both seem like tech that takes a lot of time investment while Vue.js hits the sweet-spot between features and learning curve.
That sounds like a great idea. You can incrementally add more features to sections of the page while still able to get the best of both worlds.
I bit the bullet and purchased
And I’m not disappointed. Shows you how to setup either Elm or Vue.js and really helped me understand how they should interact with Phoenix.