Fullstack scala?

Hi all,

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 ?

Thanks,
Khaled

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.

3 Likes

hah yeah that’s completely different :slight_smile:

1 Like

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.

1 Like

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.

Sure, but that’s kind of a red herring. Of course you have to use Java (and for that matter JavaScript) libraries – it’s basically impossible not to, since those are the native libraries of the platforms.

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…

2 Likes

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.

There were surprises when the compiler told me some of my Scala code could not be compiled for Scala.js, and there was some functionality that is easy to access from JavaScript, but hard to figure out or awkward in Scala.js. To use JavaScript libraries sorta-kinda as if they were Scala libraries requires some adapting code called a facade. Even for a popular JavaScript library like D3, I could not find a good facade, the best I could find was out-dated and I was not happy about some of its API. Writing a facade that exposes the full functionality while preserving type-safety is anything but straight-forward and I strongly suspect not possible in general. The code examples on the Scala.js web page using XMLHttpRequest, where the Scala.js code looks almost like JavaScript with fewer semicolons are very misleading, because in most cases, the Scala code looks nothing like the corresponding JavaScript code (and I have no idea where the JSON object in the example comes from. Note, there are no imports. It is also unusual usage, since most people would use some Scala library to parse JSON rather than using the native JavaScript JSON support).

Well, it’s been two years, maybe things have improved.

Since then, I’m just using JavaScript directly. It’s easier. Also, I’ll be likely to collaborate with front-end engineers who do JavaScript, not Scala.

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:

  1. Type inference and safety in the front end (the biggest benefit IMO)
  2. Scala helped me build better more organized code. IDE helps a lot refactoring code compared to Javascript.
  3. Shared data structures and validation code saved me from replicating code.

And here are the not so good things:

  1. Recompilation of code takes many seconds even in very powerful machines. This applies to both server code compilation to VM as well as browser code compilation. You may think that seconds is not a big deal but in reality it adds up substantially when you tweak code for front end results. On the other hand, using standard javascript in the front end and a language like Python on backend will enable you to see instantaneous results.
  2. Debugging can be a major pain. In my case, I used react inside Scala and a large amount of error stack traces (in the browser console) only showed javascript compiled code, This meant that tracing the error back to a line of Scala code was often very difficult.
  3. 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
1 Like

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.
You’ll also find a lot of facades for Javascript libraries, and writing a facade for existing JS code is straightforward.

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