Ask HN: How to switch from front-end to back-end

First start by defining &quot;backend&quot;. It means something different depending on the size of the project. Many systems now are three tier meaning front-end, middle-tier, and backend.<p>What you probably want to focus on is the middle tier. In those three tier systems the backend is actually very low level (data processing, storage, replication, message brokering, etc) and is often handled by third-party products such as database engines.<p>Some (many) projects combine backend-and middle tier as if they are the same thing. And in some systems the middle-tier is very thin and just slightly abstracts the backend.<p>So definitions aside... if you want to transition to middle tier...<p>- Learn API development. Especially focus on REST and possibly GraphQL. Learn the difference between a 422 and a 401 error, GET&#x2F;POST&#x2F;PATCH&#x2F;PUT etc, etc.<p>If you want to really get into backend...<p>- Learn hardware limitations<p>- Learn Linux very well<p>- Learn about job queues, Message busses, and interprocess communication<p>- Learn about service discovery and the differences between eventually consistent and strongly consistent<p>- Learn about containerization<p>- Learn about system operations<p>- Learn algorithms. Including graph algorithms and how to determine algorithmic complexity<p>Useful for both...<p>- Learn SQL<p>- Learn a few NoSQL systems... MongoDB, Elastic Search, Redis<p>- Learn about security<p>Don&#x27;t worry about specific languages. The concepts carry over to any language. If you have to pick, Node.js, GoLang, Ruby, and Python are all acceptable choices for middle-tier.

Honestly if you want to get out of your comfort zone and really start thinking like a backend developer, I would recommend using a solid, proven platform like Java. Specifically you could start with Java 8 &amp; Spring Boot.<p>The differences between frontend &amp; backend: frontend code tends to be more loosey-goosey, less robust. Generally the goal of the frontend coder is to write lots of features in a short amount of time. Backend development is more &quot;slow&quot;, you still want lots of features, but they need to be robust and work correctly 99.99% of the time.<p>For that reason, I think the best way to think like a backend developer is pick a language that doesn&#x27;t have dynamic objects (like Python). I&#x27;m not saying that Python can&#x27;t work, I&#x27;m saying that using a static-type language will help you outgrow any sloppy thinking habits that people tend to get when they spend too much time in Javascript.<p>Hiring wise, Java is still a very in-demand skill. Tech wise, Java is an extremely stable and proven platform that will serve any project well. It&#x27;s &quot;boring&quot; technology (which is a good thing). If you really want to change your thinking, then try to stop gravitating towards shiny things and instead use a &quot;boring&quot; platform.

Try using Django (Python) for a little while. You&#x27;ll get exposed to everything you mentioned because the Django core is feature rich. There&#x27;s a lot of support for Django—it&#x27;s battle-tested and used by a large community of Python developers. Out of the box, Django is a lot heavier than something like Tornado or Pyramid, but if your goal is to work with a widely used framework with lots of backend features to learn, I&#x27;d choose Django.

I&#x27;m currently a full time API developer using JS (Node), SQL (MySQL), and Ruby (Rails) and whatever is needed for each new project.<p>- My initial experience with &quot;coding&quot; was MySpace (HTML&#x2F;CSS) which led me to learn&#x2F;experiment with JS.<p>- Rails got me into API development because of all of its &quot;magic&quot; (even though now I&#x27;m less about magic by far); but it was a step.<p>- Having experience with HTML&#x2F;CSS&#x2F;JS made Rails easier as far as getting something up and running because I already knew what my views should look like and how to get them there.<p>- This allowed me more time to experiment and get to know Rails, leading me to discover a lot of terms and concepts I had to become more familiar with i&#x2F;e cacheing, server-side rendering, deadlocks, data-layer, and the list goes on forever.<p>- I realized the best thing to be great at, in my case, is SQL because persisting and extracting data the way you want&#x2F;need to goes so far in making other things easier.<p>- Finally, I started learning how to truly develop architecture, queues, schedule, etc once I got a job on a team where my peers and supervisors were willing to teach me.<p>Hope some of that helps!

I don&#x27;t think you can go wrong with Python. I can&#x27;t say one way or the other about Go.<p>That said; it seems to me (as just one dev&#x27;s opinion in the U.S.) that Europe -- particularly northern Europe -- has a pretty healthy Clojure scene. Of course, it&#x27;s not going to compare to Python&#x2F;Ruby&#x2F;JS in # of jobs, but if you liked it, I can tell you it only gets more fun as you learn more.<p>One general piece of advice -- internalize this: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;jboner&#x2F;2841832" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;jboner&#x2F;2841832</a> (latency comparison of different operations) as one or two operations at the wrong layer will overwhelm a whole lot of algorithmic cleverness.

You&#x27;ve received some wonderful advice about some specific technologies that you should focus on. In particular, the advice to develop strong database skills is going to be particularly helpful.<p>I want to add that because you&#x27;re experience on the front-end, your transition to the back-end will be a little easier. The best way to learn how to design an API is to consume many of them!!<p>Also, since already have front-end experience, you may find it easier to transition from front-end -&gt; full-stack -&gt; back-end only. Your front-end skills will be considered full-stack experience and when you&#x27;re in a full-stack role, you&#x27;ll have an opportunity to learn some solid back-end fundamentals!<p>Good luck with this!

If you&#x27;re familiar with JS then arguably the easiest transition route for you would be to start building some node based services on the back-end.<p>It&#x27;ll allow you to get to grips with some of the gotchas you get with back-end development with an ecosystem you&#x27;re already familiar with, once you&#x27;ve conquered those you can then start branching out to other languages and frameworks pretty easily with a solid understanding of back-end principles.<p>Another benefit of this approach is there&#x27;s a huge demand for JS engineers who are comfortable on the front and back end at the moment, so it sounds like you&#x27;re in a great position to spread your wings.

What is your goal?<p>If you want to land a job as fast as you can, you should get a team-enabling language like Java.<p>If you have some project you want to get done but need backend knowledge for it, go with a mature high productive toolset. Choose either Python+Django or Ruby+Rails and grow from there.<p>If you want a new area where you can have fun and learn new stuff, go wild with non-mature high learning curve tools like Closure or something even less mainstream.<p>If you have some very specific requirements like high availability, high concurrency, or whatever, ignore everything above and choose your toolset based on those.

I went front recruiting w&#x2F;an MBA to backend, so I&#x27;m pretty sure you can do it, too :). Not sure I have any generically useful tips beyond spending more time doing backend stuff. Write an API that a frontend can talk, figure out how to deploy a Docker container, learn SQL, etc. Backend is a pretty broad term that just means &quot;not frontend&quot;.<p>Happy to chat 1 on 1 if you like. Email in profile.

If you already know frontend programming fairly well, why not going for Node&#x2F;Express and re-use part of what you know? You will just have to study new coding approaches without having to change language as well. Once you learn how to write APIs in one language, switching to another one is pretty simple.

All I can say is to learn the spec. Like how REST works and pick a language and go deeper into it.<p>If you want to be on the safe side, go with Java.<p>It&#x27;s there and will never die.<p>You are right with FE technologies keep popping up. But you will have the same issue in the BE. New BE technologies are born to solve a different problem space such as scaling, performance, or things of that nature where as FE is more focused around HTML, CSS and JS.<p>Overall, learn generic concept which are transferable regardless of stacks such as NoSql db such as mongodb, Relationship db such as oracle db, caching with Redis or memcached, message queue such as kafka, text indexing such as elastic search, stream processing such as storm, batch processing such as spark, and a ton of machine learning.<p>With that in mind, BE is aslo rather bloated, but it evolves around more area of concerns and not just CSS, HTML and JS

Learn how is composed a request, how to build it and how you read it. Iterate on architecture rather than on features. Try out all of them, take only what you need from them.<p>Check out and learn how to use Docker and the docker-composer ; Check Python &amp; Ruby, choose to one you prefer. To me they are really great for database management (migrations) and administration; Lot of big websites use it in production.<p>Learn how to use a cache and understand why it is useful.<p>Check out GoLang and build your self a simple server. (Auth is great for a first approach of golang, i&#x27;ve been on it this week and everything is pretty much worked out by public libs) ;<p>Get back to SQL

Given that you are familliar with Javascript already. You can pick up nodejs easily. Using nodejs for a while will give you an idea of what backend development&#x27;s daily life look like.<p>Once you understand the common tasks that are involved in backend development, it will be easier to switch programming languages. Python is a good choice for example, it is very versatile and has been used to program various backend server. It is also being used extensively in scientific computing, machine learning and etc.

While I don&#x27;t have your expertise in front end development I share your sentiment and I, too, find myself prone to backend development than anything else.<p>Python is a great language used often in systems programming. It&#x27;s also a joy to code in.<p>Rust is intriguing is check it out. The build and package system is robust.<p>Go is great, too.<p>Basically you&#x27;re on the right track. Now maybe just do some study on concepts like paxos or the CAP theorem. You might look into databases both relational and not as back ends often involve those.

By learning a real programming language?<p>Well basically that was a joke, however a lot of stuff is different on the front end than on the backend. Not everything has a main event loop and async programming is not really there in many spaces. Depending on what you are doing you would need to learn a whole new programming concept, which is not that far off from my initial statement.

I would say Node, Ruby, Python should be the easier for you to get started.<p>Node: you already now JS, the ecosystem, and the idiomatic ways to do stuff. You can focus on the differences between FE&#x2F;BE<p>Ruby: It&#x27;s easy to learn, also dynamic typed, and Rails it&#x27;s a very good technology to start with backend&#x2F;MVC<p>Python: Also easy to learn, also dynamic typed. I never played with Django..

You ought to ask yourself &quot;which database do you want to learn&quot;. Make sure database transactions, consistency etc. becomes your native tongue. Being familiar with SQL and Postgres (or similar) is just as, if not more, important than Erlang vs Python vs Go.

As a front end guy (I started as a graphic designer, learned HTML, then JavaScript, then Flash&#x2F;ActionScript, back to jQuery, Backbone, Angular 1) who moved to backend, my advice is - pick anything that you feel comfortable with.<p>You have several planes of &quot;moving to backend&quot; and I will try to go over them categorically<p>1. Language: not a critical choice, but since you come from a JS background, I would stay with JS. I&#x27;d start by deciding to focus on NodeJS and that ecosystem. I wouldn&#x27;t switch to Go&#x2F;Python unless you have an urge to learn a new language. Moving to backend dev has many aspects to it. New language is not the most important one. Few aspects of languages do matter though, you have &quot;lightweight threads&quot; in Go (channels), but not in Java (unless you use Quasar). Node is not exactly multithreaded in the literal sense of it. Each language has it&#x27;s own abstraction around async computing, Scala&#x2F;Akka futures and promises slightly different than Java&#x27;s futures and promises, which are highly different than JavaScripts Promises.<p>2. Paradigm. learn both best and bad practices, patterns and antipatterns. Good to know some GoF design patterns, but also learning about functional programming, immutable design, reactive framework (RxJS for example). You will find out some of the front end philosophy is there in the backend too. Good design, OOP or Functional, has similar principles (single responsibility, loose coupling)<p>3. Databases If you want to do backend, you&#x27;ll most likely need to have an understanding of how databases work. From basic RDBMS principles, transaction isolation, ACID principles, to NoSQL, CAP theorem, Big Data etc. Learning SQL, Hive dialects etc is in my opinion an integral part of backend programming.<p>4. Security - you must understand a lot of aspects in security, from why not use MD5 to hash passwords, what is a salt, a pepper. what is Kerberos, client SSL, and why we should stop saying SSL when we mean TLS. Why you should never use DES, why you should rather not store passwords in Java as Strings but rather as char array. How to sanitize user input, and do server side validation, preventing XSS &#x2F; SQLI. What is CSRF and how to handle it on the server side. What is cookie based authentication, vs JWT. SAML, OpenID, Oauth principles. etc etc. Security must be baked into the process from start to end.<p>4. CS - as others have mentioned. Basic data structures and algorithms is a must.<p>5. Some basic OS stuff. you should know what is a page fault, virtual memory, and how OSs work in general. Caching and distributed caching, caching invalidation etc. Unless you do graphics on chips or something, then eliminating branching using bit twiddling is something I would skip... also cache alignment, unless you really are doing some really realtime stuff.<p>6. Learn architecture, especially, microservices, serverless, SOA, monolithic, 3 tier, what is a 12 factor app, what is distributed computing etc.<p>7. Learn devops and infrastructure, whether its on prem, AWS, GCP, or Azure, learn concepts such as infrastructure as code, CI&#x2F;CD, configuration management, Puppet&#x2F;Chef&#x2F;Ansible. Docker and containers, Kubernetes, Mesos. This includes learning command line.<p>8. Learn basic networking. Don&#x27;t lower than level 3 if not needed, but know how the network works

i always think, each one require a lot of knowledge, but it&#x27;s easier change from front to back, depends of the language

Not a fan of Python, but its vast ecosystem of libraries makes it a very pragmatic solid choice.

I think you might be suffering from a grass is greener situation. The web development community as a whole is unfortunately very obsessed with new an shiny. New frameworks and new languages come up fairly regularly and people jump all over them assuming that they are a solution to their problems. I think this reflects the fact that web development has the lowest barrier to entry of any programming field (there is a ton of demand and it&#x27;s relatively easy to write basic things like WordPress modules or whatever) and so young and inexperienced developers flock to it. (Which is not to say all young people think this way but I think it is more common among inexperienced developers.)<p>Personally I find that the way to avoid chasing new and shiny all the time is to work for a good organization that recognizes that is not the best way to have a stable and solid codebase.<p>In other words, I think the solution is not so much the position you have as far as front end vs. back end but where you are working.

Nearly every new programmer starts in the UI. Then, when you discover how annoying that can be, you CLAW your way out of it. I would recommend you know a backend language such as Java, .NET or Ruby. Learn it well.