• Log In
  • Sign Up
    • Cake is an impressive site. Would Cake devs be willing to share what servers, languages and frameworks they are using?

      All I can see React on the frontend. Maybe Heroku hosting it?

    • Hey @pauladv! Yep, Cake's web servers are on Heroku, with some additional services (MySQL, Redis, Elasticsearch, etc.) hosted on AWS and elsewhere.

      Cake is a universal Node.js and React app, which gives us a lot of flexibility by letting us render pages and respond to route changes on the server, in the browser, or both, using the same code.

      Happy to dive into the details if you're interested. We've spent more time building Cake so far than talking about how we built it, but there's lots to tell! 😄

    • Thanks for sharing. I thought it might be a JS all the way site given your heavy React usage. You should definitely do a write up of the stack when you have time. One last question, what Node.js web framework are you using on the backend?

    • We're using Express for routing in Node.js, but mostly for the API. User-facing Cake routes pass through a catch-all Express route and are then handled by an in-house universal routing layer that allows us to use the same code for routing and data fetching on the server and in the browser.

    • Express route and are then handled by an in-house universal routing layer

      What was the reason for going in house? Verses framework heavy?

      Node.js has been on my todo list for a long time, but I am not familiar with it. Especially keen to try doing web apps using TypeScript.

    • What was the reason for going in house?

      We knew we wanted to support client-side routing for better performance. Since Express only does server-side routing, we needed to use a client-friendly router for user-facing parts of the site. This way, when you click on a link on Cake, the browser only needs to make an API request to get the new page's data and it can then render the HTML for the page locally. This usually ends up being much faster than loading a whole new HTML page, especially on mobile.

      Initially we were using React Router for this. It's great, but it's not really designed with server-side rendering in mind. Because of this, we found ourselves having to jump through some painful hoops to be able to share code and logic between the server and the client for asynchronously loading data before rendering routes.

      So instead we built our own routing layer using some of the same components (like history and path-to-regexp) that React Router uses under the hood. This allowed us to design it in a way that met our specific needs and let us reuse the same code to load data on the server and on the client before rendering routes.