I’m fairly new to Scala and I was considering starting a project using only Scala for both backend and frontend.
I was just wondering if someone have done this in production? any feedback, gotchas?
What libraries are you using ?
I laugh every time I hear these terms back-end and front-end. From my heritage VLSI design, back-end is physical verification and front-end is schematic capture and layout generation. I had some colleagues who spoke English as a second language who also referred to another part as the middle-end.
I have – my company is basically full Scala end-to-end. (It’s open source – here’s the repo. Note that the code quality varies wildly, since much of the code dates back to 2013, when I was still fairly new to Scala myself. It’s also way behind the times, still on Scala 2.11.)
On the front end, I wound up building my own framework. I do not recommend this: I did it because I was building basically the first production product using Scala.js (this was around six years ago), and there weren’t good bindings for more mature frameworks. I gather that a lot of folks have had success using React, and there are now several different bindings for it.
My APIs are all built with Autowire, and that’s been a joy. It means that the API definitions themselves are Scala traits, so I have strong types from end to end – I can make a change in my back-end Actors, and have the compiler guide me all the way through to the front end changes that I need to make as a result.
hah yeah that’s completely different
ah interesting that’s actually one of the reasons I’m interesting in using one language all the way is reuse!
what would you choose if you were starting that project today?
what would you do differently ?
FWIW I think full-stack development in scala exclusively is a pipe-dream. Not using good java-libs out there would be plain old stupid. My company code in Scala, is a “full-stack-shop” but use established, some might call conservative, java-frameworks like JPA (EclipseLink) and Spring, even AspectJ. I’m very glad we didn’t jump the “re-write all in Slick”-wagon… when Slick was part of the “move away from JDBC/JPA-code” hype. We’ve been in this business for long enough to appreciate the stability of those frameworks and will have to provide support and development for our product for at least 10 more years. We consider every framework we use carefully. We’re using Lift for front-end/GUI-work and have been for 8 years now, never regretted it.
I do my own side-projects in full-stack Scala with Play on the back-end and Scala.js on the front-end with Slinky as the React binding. I enjoy it, but I can’t comment on how well it scales up to full commercial projects. I force my students to use that stack by the end of the semester as well. The videos I made for that course are at https://www.youtube.com/watch?v=FqMDHsFNlxQ&list=PLLMXbkbDbVt8tBiGc1y69BZdG8at1D7ZF.
Like I said – I’d choose a mature front-end framework like React.
Aside from that, frankly, it’s been a joy – I’ve had no regrets.
But I disagree with you about your choice of stack. The various Scala-centric stacks work extremely well. (I’ll agree that Slick is controversial – but that’s why everybody is using Doobie and Quill these days.)
I use primarily the Lightbend stack (plus some Cats) for my own little garage startup, as well as at work (a pretty large Scala-centric company), and it’s served us well. (Also for about 8 years in both of those cases.) Yes, that platform has been growing and improving over those years – I don’t think that’s a negative…
About two years ago, I wrote a prototype for a web app using Scala full-stack, i.e. a Scala server serving a Scala.js web page.
On the one side, it is pretty amazing what Scala.js can do, but on the other side, it is still disappointing in terms of developer experience.
Well, it’s been two years, maybe things have improved.
Not production in my case.
However, I have significant experience putting together a personal project with Scala.js + Play Framework.
I did this about 9 months ago.
The idea of sharing code, specially data structures and validation, between front end and back end is interesting.
You will likely want to have a shared library that will compile both in browser and server. For this you need to make sure you use libraries that have been compile for both browser and server. FYI, not all libraries have been compiled for both. Even when they have, you need to make the versions for both server and client match.
Here are they key benefits I achieved while using full scala stack:
- Type inference and safety in the front end (the biggest benefit IMO)
- Shared data structures and validation code saved me from replicating code.
And here are the not so good things:
- Since Scala.js compiles to JS, you need to be aware of some unexpected behaviors due to the nature of the compiled language. Check https://www.scala-js.org/doc/interoperability/exceptions.html
As I worked in FPGA industry, we had a slightly different version of front vs back end.
Front end was HDL design, synthesis and HDL simulation (namely in VHDL or Verilog)
And back end was map + place and route and post place and route simulation
I started using Scala.js in production two years ago and never regretted it.
The main difficulty was to get the full-stack sbt setup right, but you can find several sample projects on github.
If you like the React approach I can recommend scalajs-react.
Otherwise scaltags is very convenient for client and server side rendering.
You can even write CSS in Scala with scalacss, which intergrates nicely with scalajs-react and scalatags.
For client/server communication my favourite is sloth, which is quite similar to autowire.
I do small tweaks (styling, layout etc.) in the browser’s dev tools and copy the result to the source code
I was impressed how well debugging the Scala sources works in Firefox and Chrome.
right, you have to be aware that you are targeting a different platform, but I don’t see any problem with this