Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What tech stack would you use to build an open-source Google Keep clone?

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 128 posts

Ask HN: What tech stack would you use to build an open-source Google Keep clone?

#1

Post by mud_dauber »

I'm sick of waiting for Google's Keep team to improve their app, or even to respond to feature requests. (Crickets.)

So I'm going to attempt to build my own - despite being a real noob when it comes to JS-based tech stacks. What would you use as a starting point for a tech stack, if you want:

- public/private/sharable card options - import/export to a couple of mainstream alternate formats - reasonable response times - an improvement over downloading the entire DB upon page load - markdown-capable cards - sort/filter/tag options

I'm assuming this is going to be some flavor of Angular/Vue/React. Suggestions?

Re: Ask HN: What tech stack would you use to build an open-source Google Keep clone?

#3

Post by fouc »

Take a look at Riot.js or Mithril.js if you want something much simpler and easier to pickup quickly. Another great option might be Svelte & Sapper (Sapper is for Svelte like Next.js is for React)

Try focusing on finding ES6 approaches and that'll help keep your code simple also.

Re: Ask HN: What tech stack would you use to build an open-source Google Keep clone?

#4

Post by joduplessis »

You can roll out your own app using a frontend framework together with a backend one - like Node, PHP, .NET, etc. Using something like Firebase, a backend framework becomes less relevant - but some of those features you listed are deceptively complex. My suggestion would be to pick up Angular or VueJS together with Firebase. React can be tricky if you're starting out.

Re: Ask HN: What tech stack would you use to build an open-source Google Keep clone?

#6

Post by polote »

Any Js framework will work, also vanilla js will work.

Just pick a framework that you want to learn and do this project on this framework. Also if you want to learn vanilla js, pick vanilla js.

And for the backend side, same story, pick whatever framework and language you prefer. Superior framework at the scale of a side project doesn't exist. And personally I would pick vanilla js with Django because that is the stack I know the best

Re: Ask HN: What tech stack would you use to build an open-source Google Keep clone?

#7

Post by 0x420 »

As far as your backend design goes it really depends on your scaling needs and how much of a purist you want to be about keeping your dependencies open source. If I was just trying to scratch a personal itch I would write it as a Typescript w/ Apollo GraphQL hooked up to a managed Postgres and running on a serverless platform like AWS Lambda. I’d probably write the frontend in React with some kind of state management library.

Re: Ask HN: What tech stack would you use to build an open-source Google Keep clone?

#9

Post by tga »

At its core, Google Keep is a relatively simple web app. Especially for a low traffic scenario, literally any web framework/library and combination will be good enough. You need storage, a backend, and a front end, either all from the same package or talking to each other.

I suggest you figure out what looks interesting to learn and go with it. You can also “outsource” parts e.g. getting storage and backend as a service from something like Firebase, so you can focus only on building the front end.

Re: Ask HN: What tech stack would you use to build an open-source Google Keep clone?

#10

Post by saulrh »

If you want people to keep their notes in it, it's going to have to advertise stability and longevity. Ruthlessly cut dependencies/requirements and avoid using features that may change under you as time goes on. Use a simple data-store built with common tech (json, sqlite, straight text files, etc) so people can get to their data even if your code disappears off the face of the Earth one day.

For the frontend, then, we're talking tables and forms. Really simple lowest-common-denominator stuff. Design the API before touching any of the code - that's the only place where "without pulling the entire DB at page load" can happen. Build the backend in something with a safe, stable standard lib or core ecosystem, python or common lisp or the like.

Of course, those are ultimately stretch goals. Like another commenter here said, use whatever you're most comfortable with. On the vast majority of software projects the biggest obstacle is the programmer. I can't really help there because I don't know what you're familiar with. Sorry. Good luck.

Post reply on HN