8 ms·

Frontend: (vanilla) React with TypeScript. - TypeScript is more important than React, static typing is such a productivity boost, even for projects of all size

by Retozi 8y ago

Frontend: (vanilla) React with TypeScript. - TypeScript is more important than React, static typing is such a productivity boost, even for projects of all sizes. - Start with vanilla React and create-react-app, monitor for painpoints and look for solutions for these pain points in the community, don't look at the whole ecosystem before you start building stuff. Backend: Kotlin on the JVM. Kotlin is a really nice language for either functional or object oriented programming. Static typing with strict null checks are again a huge productivity boost. Standard library is very complete Beeing on the JVM without beeing stuck with Java is a big win: - unlocks a huge ecosystem and Java interoperability of Kotlin is superb.There are a lot of lightweight frameworks for stuff around here, enterprise Java is a myth if you are free to choose what to use. - special shoutout to the JOOQ library, the golden middleground between an ORM and raw SQL Strings. - JVM is fast - fat jars are somewhat like containers, can be run everywhere with minimal setup (yeah I'm looking at you python-uwsgi black magic) Database: Postgresql. Everything you need (relational, JSON), fast, rocksolid

cies 8y ago
At this point this would prolly be my advice as well. From React/TS, to Kotlin, to PG, to the JOOQ shout out. I hoped a strongly(ish) language that spans from BE to FE, like ReasonML, would be ready by now, but it isn't. Kotlin to JS is not there I'm afraid: https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-j...
- Felz 8y ago
  What's not there about Kotlin/JS for you, out of curiosity?
  - gregopet 8y ago
    Interop with other JS libraries for example - Vue in our case. We switched to Typescript mid-project and never looked back. Server is still Kotlin and we just export the data transfer classes as Typescript definitions (using a library we found on GitHub that works well enough).
AsyncAwait 8y ago
Wanted to look into Kotlin on the backend for a while now. Do you use any framework or do you just assemble individual libraries for whatever you need? I am not sure I find Spring an attractive proposition and Ktor seems rather young, slow and not that well documented. What do you think is the best option?
- Retozi 8y ago
  I'm personally in the "functional handler" way of doing HTTP Request camp. We have a very small Ktor service in Production, and it works nice, for legacy reasons, we're using http://sparkjava.com/ http://sparkjava.com/ for the heavy lifting. An alternative would be https://javalin.io/ https://javalin.io/ I would not start with Sparkjava anymore. The way you write handlers is quite okey (compared to other frameworks), but there are issues with how it's connected to Jetty and relies on singletons that will be painful if you would like to do advanced stuff. It's on our todolist to swap Sparkjava with Ktor somewhere down the road. To be honest, Ktor seems to have come a long way, the docs improved a lot last year and it seems well thought out. I would give it a try. It's quite easy do decouple your application Handlers from the underlying framework via functional composition, so there is no big lock-in Risk. In my experience, all three Frameworks are way better than the regular Java-like approach with annotating classes. Request-Context specific information ("The user making the request") is very hard to get to this way and it's usually untyped. On top of it, you are locked in HARD to the Framework. Swapping out a Framework that just mounts Functional Handlers is way easier...
  - AsyncAwait 8y ago
    Thanks for the writeup, Javalin looks like what I was looking for honestly, but I'd check out Ktor again as well. EDIT: Ktor does look a lot better today and now that Kotlin coroutines are actually stable, I'd definitely check it out.
  - russelldavis 8y ago
    Has anyone used both Ktor and Javalin and have any advice for choosing between the two?
- 8y ago
gregopet 8y ago
I .. cannot upvote this enough :) We're using an almost identical stack (Vue instead of React, but that's about it) and we love it! Going back to old projects using various ORM products makes me cringe nowadays, JOOQ + Postgres are such a powerful combo!
matte_black 8y ago
Curious to know if you tried React with Flow before choosing to go with React and Typescript.

by Retozi 8y ago

cies 8y ago

At this point this would prolly be my advice as well. From React/TS, to Kotlin, to PG, to the JOOQ shout out. I hoped a strongly(ish) language that spans from BE to FE, like ReasonML, would be ready by now, but it isn't. Kotlin to JS is not there I'm afraid: https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-j...

Felz 8y ago
What's not there about Kotlin/JS for you, out of curiosity?
- gregopet 8y ago
  Interop with other JS libraries for example - Vue in our case. We switched to Typescript mid-project and never looked back. Server is still Kotlin and we just export the data transfer classes as Typescript definitions (using a library we found on GitHub that works well enough).

AsyncAwait 8y ago

Wanted to look into Kotlin on the backend for a while now. Do you use any framework or do you just assemble individual libraries for whatever you need? I am not sure I find Spring an attractive proposition and Ktor seems rather young, slow and not that well documented. What do you think is the best option?

Retozi 8y ago
I'm personally in the "functional handler" way of doing HTTP Request camp. We have a very small Ktor service in Production, and it works nice, for legacy reasons, we're using http://sparkjava.com/ http://sparkjava.com/ for the heavy lifting. An alternative would be https://javalin.io/ https://javalin.io/ I would not start with Sparkjava anymore. The way you write handlers is quite okey (compared to other frameworks), but there are issues with how it's connected to Jetty and relies on singletons that will be painful if you would like to do advanced stuff. It's on our todolist to swap Sparkjava with Ktor somewhere down the road. To be honest, Ktor seems to have come a long way, the docs improved a lot last year and it seems well thought out. I would give it a try. It's quite easy do decouple your application Handlers from the underlying framework via functional composition, so there is no big lock-in Risk. In my experience, all three Frameworks are way better than the regular Java-like approach with annotating classes. Request-Context specific information ("The user making the request") is very hard to get to this way and it's usually untyped. On top of it, you are locked in HARD to the Framework. Swapping out a Framework that just mounts Functional Handlers is way easier...
- AsyncAwait 8y ago
  Thanks for the writeup, Javalin looks like what I was looking for honestly, but I'd check out Ktor again as well. EDIT: Ktor does look a lot better today and now that Kotlin coroutines are actually stable, I'd definitely check it out.
- russelldavis 8y ago
  Has anyone used both Ktor and Javalin and have any advice for choosing between the two?
8y ago

gregopet 8y ago

I .. cannot upvote this enough :) We're using an almost identical stack (Vue instead of React, but that's about it) and we love it! Going back to old projects using various ORM products makes me cringe nowadays, JOOQ + Postgres are such a powerful combo!

matte_black 8y ago

Curious to know if you tried React with Flow before choosing to go with React and Typescript.