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

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

#51

Post by spinningslate » Sun, Feb 03, 2019, 5:52 PM UTC

mud_dauber wrote: post #44

spinningslate wrote: post #41

Warning: this is deliberately not following mainstream convention/fashion. It's hopefully useful, but feel free to ignore if you'd prefer not to explore beyond more conventional options. First off, a few requirements I inferred from your Q: 1. Performance (response time + concurrency) 2. Simplicity (you're a noob, but it's always a good thing anyway) 3. Stability + ease of maintenance/evolution (you don't state this…

Interesting. I just spent a couple of weeks learning Elixir & really liked it. Any disadvantage to doing the backend work in Elixir instead?

> Interesting. I just spent a couple of weeks learning Elixir & really liked it. Any disadvantage to doing the backend work in Elixir instead?

I haven't really used Elixir so can't talk from experience. I did look at it but just prefer Erlang syntax. I hear good things about the language, ecosystem and community though. Phoenix seems really well-regarded as a web framework (and indeed, there is/was some integration with Elm).

It uses Erlang's underlying VM (BEAM) so benefits from the stability and concurrency BEAM brings. So I don't see any obvious downsides.

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

#52

Post by oyebenny » Sun, Feb 03, 2019, 5:53 PM UTC

Holy should I thought I was the only one I'm giving them feedback literally every other week. I keep reminding them that they should just hire one intern. Like literally send a 12 year old to improve the app for 3 months and they'll find a many ways by themselves. This is not even a snail's pace; perceivably it's as if literally no one to sign to it at Google.

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

#53

Post by PascalW » Sun, Feb 03, 2019, 5:53 PM UTC

If you're going to build an open source product that you want people to host on their own servers then a few things are really important:

- Ease of deploying.

- Amount of resources required to run it.

I've been building an open source notes app recently and I picked Rust + ReasonML and React in the front end.

It's super easy to deploy; it all compiles down to a single native binary that contains both the server and frontend.

It's super easy to deploy this, with or without Docker. It consumes almost no resources at all. The binary is 12 MB and consumes around 5 MB of RAM.

On the frontend it's a PWA, so it's available offline too. This is the most important part. You could build the PWA in other frameworks as well.

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

#54

Post by ummonk » Sun, Feb 03, 2019, 5:54 PM UTC

chooseaname wrote: post #43

ummonk wrote: post #35

What would I use? Standard tech stack: React+Apollo+Redux+GraphQL (with Typescript). React Native for mobile. On the backend, Postgres DB at first, upgrade to CockroachDB or something when needing scale. Choice of language for application server to translate GraphQL queries to and from SQL queries is the only thing I would be unsure about - either Python or Typescript probably. But this is because I'm very familiar w…

> Standard tech stack: React+Apollo+Redux+GraphQL (with Typescript). The standard or A standard?

Nearly all the new startups I interviewed with recently were using that stack, except some had vanilla JS or were only partially converted to TypeScript.

It's becoming the de facto standard stack for new projects.

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

#55

Post by Klathmon » Sun, Feb 03, 2019, 6:03 PM UTC

PascalW wrote: post #53

If you're going to build an open source product that you want people to host on their own servers then a few things are really important: - Ease of deploying. - Amount of resources required to run it. I've been building an open source notes app recently and I picked Rust + ReasonML and React in the front end. It's super easy to deploy; it all compiles down to a single native binary that contains both the server and f…

This might be off topic, but how are you liking reasonML?

I've been meaning to pick it up for a while now and keep reading over the docs but still haven't done much. Would you be willing to talk about some of the pitfalls and rough edges you've hit or things you would do differently?

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

#56

Post by wtmt » Sun, Feb 03, 2019, 6:08 PM UTC

I'm going to throw this one back at you:

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

Choose a stack that:

a. has many developers using it on GitHub (since that happens to be the most popular platform for hosting open source code)

AND

b. is easier to use or fork as well.

Life will take over at some point after you develop some version of a Keep alternative. It may be the same as Keep today or lacking a lot comparatively or better than it. In any case, you'd need something that others can contribute to (sending pull requests), fork and create different/better versions of, etc. If you go with some relatively obscure stack or a dying stack because it promises to be fun or promises that you'll learn something new or promises something very fancy, then you'd either not get many users for your application or would have people in the future screaming the same sentence you started with above.

In other words, try not to do to others what you imagine the Google Keep team has done to you (or not done for you)!

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

#57

Post by CalmStorm » Sun, Feb 03, 2019, 6:19 PM UTC

As a customer, I would like to use a zero knowledge application for note taking. I don’t want my notes leaked due to security breaches. I also don’t want them to used for other purposes such as data for machine learning without my permission. My notes should always be encrypted and I am the only who has the key.

You may want to take a look at Bitwarden to see how they do it. It is open source. You can use the similar architecture for client side encryption and decryption, and extend it to note taking.

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

#58

Post by ibnishak » Sun, Feb 03, 2019, 6:20 PM UTC

burtonator wrote: post #36

You could take a look at what I'm building with Polar: https://getpolarized.io/ It's basically note taking but integrated with the reading flow. You basically keep all your books and notes in one place and you can annotate and highlight directly within Polar. It's basically a "personal knowledge repository" with all your books and web content integrated along with highlighting.

Just letting you know, if you ever build a android app, I will download the paid version happily.

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

#59

Post by fouc » Sun, Feb 03, 2019, 6:34 PM UTC

mud_dauber wrote: post #47

jamil7 wrote: post #38

Earlier quoted context omitted.

If you're goal is to get the app done and published rather than learning a new tech then go with your default stack. I've never worked with Rails but it seems like a totally valid choice for the product. You can always bolt on a more modern frontend later if you need it.

Thanks. It's Rails' frontend performance stigma that made me hesitate. I suppose bolting a better FE is an option, but I won't know it until I benchmark it.

I'm a rails dev too, last year I was making a mobile web app where I was concerned about frontend, so I started making a SPA in mithril.js and using Rails as the API.

Later I abandoned the SPA and went back to rails views, using turbolinks to make it fast. In reality rails + turbolinks is fast enough for most cases, and then I can sprinkle in extra javascript or use SPA on one or two pages as needed.

The reason I think it's almost better to avoid SPA + API approach is to keep the codebase simple and easier for one person to maintain.

https://www.youtube.com/watch?v=SWEts0rlezA http://masilotti.com/beermenus-and-turbolinks/

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

#60

Post by PascalW » Sun, Feb 03, 2019, 6:49 PM UTC

Klathmon wrote: post #55

PascalW wrote: post #53

If you're going to build an open source product that you want people to host on their own servers then a few things are really important: - Ease of deploying. - Amount of resources required to run it. I've been building an open source notes app recently and I picked Rust + ReasonML and React in the front end. It's super easy to deploy; it all compiles down to a single native binary that contains both the server and f…

This might be off topic, but how are you liking reasonML? I've been meaning to pick it up for a while now and keep reading over the docs but still haven't done much. Would you be willing to talk about some of the pitfalls and rough edges you've hit or things you would do differently?

I think it's very promising, but it definitely has some rough spots.

Things I like:

  * It's a general purpose language, it's not only usable on the front-end (like Elm for example).
  * It's a really powerful language (or rather, OCaml is).
  * Interop with JS is good. It takes a bit to get used to the syntax for writing bindings, but once you get the hang of it it's pretty straightforward. Again, ReasonML IMO scores a lot better in this front than Elm.
  * ReasonReact is a very thin wrapper around React, so if it's really easy to work with if you already know React.
  * There are other options than ReasonReact, for example bucklescript-tea [1] which is very Elm like.
  * There seems to be a lot of focus on targeting native. See for example Esy [2]. There's some real potential in bs-react-native [3] and Revery [4].
  * Overall the experience of working with Reason is really great. The compiler has your back, is great at type inference and the syntax is pretty elegant (though IMO a little less so than Elm).
  * The compiler is blazingfly fast. Blows Typescript and Babel out of the water.

Things that are a bit rough:

  * Docs are spread across Reason docs, Bucklescript docs and OCaml docs. A lot features are not documented in Reason, because they're inherited from OCaml. If you would read just the Reason docs you might get the impression that's a pretty small and simple language, but it's actually very powerful. If you're thinking about picking up Reason I definitely recommend you read the RealWorldOCaml book [5].
  * The Reason syntax is a bit weird in some spots. If you make a syntax error the compiler will in most cases just yell `Error: Syntax error` at you which is not really helpful.
  * The ReasonReact API feels a bit alien, probably because it's build on top of the React Class API. I think there a bit some big changes coming to ReasonReact though, so hopefully this will change.

Things that concern me:

  * There's little formal communication about the direction and future of the project. It seems to be mostly Facebook who's behind it, it doesn't feel like a community project at all. Bucklescript seems to be largely a one man show.
  * There have been a handful of Bucklescript and Reason releases that plain broke stuff. Of course this can happen, but it does make me a feel a little uneasy.

All in all I'm definitely positive. There's a lot of potential and hopefully when Reason picks up some more steam it can become more a community project. Be sure to check out the Reason Discord [6], very helpful people there!

[1] https://github.com/OvermindDL1/bucklescript-tea

[2] https://esy.sh/

[3] https://github.com/reasonml-community/bs-react-native

[4] https://github.com/revery-ui/revery

[5] https://dev.realworldocaml.org/

[6] https://discord.gg/reasonml