What do Rust jobs with "backend" in their title mean?

1

I am under the impression that for most web backend APIs Rust is a bit over-kill, as the majority of time is spent in HTTP request/response cycles, database IO etc. In this case mature CRUD frameworks like Django/Rails or even Play seem more appropriate. BTW I understand the benefits Rust gives you of stronger type-safety etc. vs something like Python/Ruby/JS...
.

However when I search for "Rust jobs" I find a lot of ads with "backend" in the description, but not much more detail. Does this mean these projects involve writing backend APIs in Rust, or rather mission/performance critical parts of the backend in Rust? Or am I simply conflating "backend" with public APIs over HTTP?

Real-world clarification would be much appreciated in terms of what people generally mean when they talk about backend Rust development.

2

"backend" implies that there is also a "frontend" somewhere. I'm sure you will find as many interpretations of such terms as there are applications.

In our current projects we do indeed refer to "frontend" and "backend". We use them in a way analogous to physical shops or other businesses. Shops have "shop fronts", other businesses have "front desks". They refer to such things as "back rooms". So "front" is what faces the outside world and is the interface with customers and clients. "back" is all the work going on behind the scenes that customers never get to see.

In our case "frontend" is your usual web pages and REST API's. Along with web socket streams and such made available to clients. So that is Nginx and web servers built with Rust and Rocket and web sockets served by Rust and Tunstenite. Sadly we still have a lot of Javascript for browsers to consume.

Meanwhile the "backend" is a lot of corralling and processing of data incoming from remote sensors and other machines. Communication between our servers. Databases and so on. There is a lot of Rust code in their performing performance critical work, we need good throughput and low latency, which cannot be done with the likes of node.js. Python and the like. But still we do have a lot of Python in there as well.

1 Like
3

Performance is not the only reason for using Rust. Backends provide the ground truth and the bulk of the business logic – they should be as correct as possible, so a strict, statically-typed language can be a better choice than a dynamic scripting language.

It may be either. Jargon is not precisely-defined, unfortunately. You'll have to ask those responsible to elaborate.

7 Likes
4

So in your case when you speak of front-end you may be speaking of a Restful API, when others might refer to that as a "Backend."?

A use-case for Rust might be processing large amounts of data (offline) from the actual API server code, but the actual HTTP server code might be written in something more agile, like Python etc?

5

In this era of microservices those mission/performance critical parts itselves would be their own services with backend APIs.

1 Like
6

The issue of REST API's and "front/back end" are orthogonal. The front end may well serve up web pages, REST API's and web socket streams to clients out in the world. In turn the back end may well serve REST API's and web socket streams to the front end.

It's API's all the way down...

To my mind a use case for Rust is in creating reliable software with high and predictable performance. That is to say all software. Front, back, sideways, on servers, on embedded systems, whatever. That is what we are doing here.

I'm not sure what you mean by "offline" there. I usually take "offline" to mean some processing that is done as a big job that has no real-time requirements. We process large amounts of data, continuously, all the time. A lot of that processing is what we call "back end". It happens out of sight of the end users. In the "back office" as they say in the physical world.

It might be. I see no reason for it though. We use Nginx at the very front of our front ends. Only acting to handle HTTPS and certs, and as a proxy passing requests on to our actual servers that are created in Rust using Rocket.

I really don't want to go back to a wobbly, poorly performing, mess of scripts created in Python or node.js or whatever.

I'm not sure that "agile" has anything to do with it. Agile is an approach to design and development. It says nothing about what language one is using.

Sure it feels so much easier and quicker to knock up a quick script in whatever scripting language. Perhaps even easier to modify such creations when they are still small code bases. This gets increasingly, and rapidly, more difficult as projects grow, especially if more than one person is working on it.

At this point you find you can have far more confidence in modifying Rust code without breaking anything. Thanks to Rust's strict type checking and lifetime checking.

2 Likes
7

Right so this is one of my motivations for exploring Rust/Go etc. and I think why a lot of Python/Ruby/JS developers are exploring it. I think we've come to a point where the majority of our "accepted" languages are not up to the task of development at scale.

I played with Go a bit and it's better than Python/JavaScript etc. but a few things bother me about it:

  1. The error handling is maybe better than exceptions in that you are kind of forced to deal with them up-front. That said, the compiler doesn't stop you from dealing with errors (though of course in Rust you can unwrap, but that's a bit more explicit. Further coding in Go is not fun. It's terribly monotonous, mainly because of the error handling. This constant error handling also makes it hard to visually parse.

  2. I see plenty of run-time errors (due to null pointers) that should be caught at compile time.

In terms of typical CRUD APIS perhaps dealing with a loosey goosey language is, in the long-term, worse than having to glue more stuff together like you'd have to do with Rust as opposed to say Django.

2 Likes
8

In particular, I like the idea of having my domain model be type-checked code (as opposed to string-based descriptors loaded from who knows where, or plain English prose that is out-of-date). Having that same level of tight integration with a database would be nice, but we are not there yet AFAICT.

2 Likes
9

That is my take on things and is certainly a major reason why we have moved from javascript and node.s to Rust. Even though our scale is not even so huge.

I'm not so experienced in Go so won't comment much. Save to say that back when node.js was the new kid on the block and both node and Go were new to me, my experiments showed that Go was not much faster than node.js for a major task we wanted to do and suffered from worse "jitters" than node.js. Not good as we needed low latency. We went with JS at the time for it's simplicity and the fact that using the same language on the server as in the browser was convenient.

I'm wondering what you mean by "glue more stuff together" there. I know noting of Django but using Rocket and a handful of other dependencies to create a REST API in Rust does not seem very onerous. Similar in fact to bolting modules together when doing the same in node.js. I personally have an aversion to overarching frameworks that end up dictating how your whole project is written.

10

Django handles migrations and pretty much everything else under the sun for the majority of use-cases. Another nice thing with Django/Rails is a built in admin script framework that normalizes how you'd use scripts to interact with your bootstrapped models etc. Auth and all that stuff is either built-in or there are accepted, well tested libraries. And nice for prototyping, at least in Django, is a pretty powerful admin GUI interface for your models. I wouldn't want to write that all by hand. I did an experiment with Go that required me to do much more hand-coding and I gave up trying to prove to my boss that it was worth it. Perhaps the story with Rust is better, or I am over-estimating the convenience of these items, but they are things I have used over and over again in the real world.

I am open to being wrong, as always, and believe would love to use a more robust language even for prototyping. The problem with prototyping is it often becomes production code.

11

We live in different worlds. I don't even have any idea what "normalizes how you'd use scripts to interact with your bootstrapped models" might mean.

As such I can't comment on the state of whatever is available in Rust to perform the functionality of the frameworks you mention. I suspect it is not there yet.

Except I feel that it is not a good idea to give up whatever you have and start rewriting it all in Rust just for the sake of adopting a new language. Not unless what you have now really does not meet the requirements you have. Not unless you really want to take on such a framework in Rust as a project in itself.

Likely a "softly softly" approach would help. If the is some small part of your system that underperforms or gives endless problems with bugs and such, then it is a candidate for reimplementing in Rust. If that works out then you have a case for tackling other components with similar issues or new components. The point being there has to be a valid and convincing reason for switching to Rust here and there rather than demolishing the whole house and starting over again.

Pretty much always. Actually I think all code that has made it to production is still prototype code. It's the prototype for the next release. Things can change majorly between releases. And so on, until the product is unmaintained, unused and dead. Or its a prototype for your next project.

Turns out that the prototypes in Rust that we pressed into production two years ago have worked very well since. I'm sure by any seasoned Rust programmers standards they are very poorly though out and written Rust. Being a newbie my Rust is written either like C or like Javascript! The fact that the compiler prevents one from shooting oneself in the foot in so many ways has meant that incompetence has not been a problem.

1 Like
12

I wouldn't think of re-writing for the sake of rewriting. I am just exploring Rust as I have very little experience with languages like C and Rust. I actually started teaching myself a bit of C, going through some book just so I'd understand better what problems Rust is trying to address.

On a separate note I'm kind of tired of developing the same thing over and over--that is full stack web development for typical web apps/mobile. Apart from being tired of solving the same thing over and over again, the culture of web development tends to be loosey goosey, even with some improvements like TypeScript. I think this may be partially because it tends to draw people with less of a CS focus. It may also be a relic from the early days of the Web when the browser just wasn't a mature development environment.

Suffice to say I am also looking to get into another development field...I'm just not sure what yet. Some kind of lower-level Systems Programming. I like what I see from Rust so far because it doesn't let you get away with crap, can operate closer to the machine, yet has great tooling (Cargo etc.), fantastic documentation, and great elements from the functional world, including Result/Option enums etc.

13

I think that is an excellent idea. Either C or assembler, to get a good feel for how things work in reality, about stacks, pointers, and all the rest.

All the best in your efforts to find more interesting work.

14

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.