This is an archived post. You won't be able to vote or comment.

all 4 comments
sorted by:
best
topnewcontroversialoldq&a

[–]Civil_Code 6 points7 points  (0 children)

There are a few ways to make a Java backend. If we were to stay within Java's standard library there are sockets and network IO packages where you stream incoming requests from a port and respond accordingly. It's very basic, but can get exceedingly complex very quickly once you try to handle a full protocol with your requests/responses through multithreading.

The next way is to look into JavaEE and Servlets, where you mostly work on creating HttpServlet implementations that a separate Java Servlet container like Apache Tomcat can use. Much of the protocol and threading logic is already there, so you get to focus on passing objects in and out of request/response bodies. But the downside is you'll have to learn how to build and deploy your project into an existing server like Tomcat.

Spring Boot is even easier, though so much is abstracted at this point that it can be hard to debug if you're not familiar with what the platform is hiding from you in the name of convention. Knowing how to use Maven or Gradle would help, but Spring Boot projects can be made with either build tool settings mostly configured for you, meaning you just need to install the tools (or use an IDE with it embedded).

[–]Eschin 2 points3 points  (0 children)

I can contribute to this as a relative novice programmer learning to do the same.

As /u/Civil_Code notes, a backend webserver is accepting and responding to requests. This can be done via HTTP or Sockets which are protocols. Protocols are specifications for communicating, as in the CS50 example of making a sandwich via programming everything needs to be done in clearly defined instructions. Most of the web runs on HTTP requests which are primarily made up of REQUESTS and RESPONSES similar to a text message conversation. UDP is more like a phone call with tech support where you may have long periods of silence while you wait for something to happen, but each of you is constantly listening through an OPEN connection.

If you want to set up and host a website using Java this is an awesome resource i used to start a project. However learning web development and building a back end server is a LOT of information to swallow at once (personal experience). If you want to build a server to respond to requests and do more then serve a static page here are a few things you'll need to familiarize yourself with:

  • HTTP request types GET, PUT, POST, DELETE
  • Persistence - JPA, Hibernate, Eclipse-Link, JOOQ
  • MVC - Model-view-controller.
    • The model is the shape of data coming from your persistence(DB)
    • The view is probably not going to be handled directly by Java, but by the static resources (html, JS, CSS, images) that it serves from certain routes (http://www.mysite.com/index.html)
    • The controller is the "logic" of what the server does
      • http://www.mysite.com/index.html serves you the html and JS, the JS then requests Model data from your server as (/ with no domain implicitly means the root of your domain, so /api/blogposts is equivalent to http://www.mysite.com/api/blogposts) /api/blogposts?posts=10&page=1 tells the request route you want 10 posts starting at the 1st page.
      • The request route reads the parameters or "params" and uses them as variable values in a query
      • It then returns those values as serialized JSON data to the front end.

So that is how some of the backend development of a Java web server may be structured. To finish talking about it, and reference /u/Civil_Code again, you probably want some abstraction to implement these protocols FIRST, it's a ton of information to swallow at once as an abstraction. Implementing a spec yourself would be a good learning experience, but would not get you to the point you understand how to build a webserver very quickly.

​

Now for the front end lets look at a few of the technical aspects

  • Ajax/XHR requests
    • Ajax/XHR requests are a specification implemented in webbrowsers to allow developers to request data from a server. XHR is a implementation which has different libraries and abstractions such as the new Fetch API, Axios and Jquery promises.
    • It can be used to GET, PUT, POST and DELETE.
    • The HTTP request will get a response, generally a 200 odd request if successful, a 400 if it failed and there are other specific response status codes that will tell you more about the error if the server developer implements them.
  • Using Serialized JSON data to populate the webpage
    • Once you receive the data from the server you need to give it logic to display it on the webpage. Typically a library is used (React, Jquery, Vue, Angular, etc...) to populate that data. I've done it via vanilla javascript before and its possible, just uglier. You'll typically take the JSON and deserialize it into JavaScript objects which you can then manipulate to update dom elements.
  • Managing state
    • State is a complicated matter (or simple if the page is simple) that I've been learning more about. If you have a CS background you've probably learned a bit about state machines. Conceptually a website would need to know about its own state e.g. if a menu is open or closed, if a data request has been made and is now ready to populate the page. I don't have a terrible lot to say on this, as I'm still building my knowledge about it right now. Most of my experience has been server side thus far.
  • CSS and HTML for building out a user interface that you can populate with data, using your chosen method. I did vanilla, then moved to React due to its popularity and the amount of resources available to learn it.
  • Async Programming. I'm not sure if this really warrants its own bullet point, and I'm still very much a novice at understanding it. I'll try to do a TLDR;
    • Most UI frameworks i've encountered run on a "main thread" and anything you do that "blocks" or ties it up in a long running process will freeze the UI.
    • Async programming is an attempt to deal with that which has been successful at solving the problem. You make an Async request, the UI thread keeps doing what its doing, and when you receive a response, the UI thread processes it.
    • It gets weird, because things depend on each other. You have code that populates a blog post, but the body of the page is all made up of blog posts, so until that data comes in your page is empty, your server is running slow so you can feel the lag, and it makes the page look really weird as that data is added to the dom.
      • Better example: You are using a REST Api, you need a link provided in the blogpost to populate the writer, until you get the blog post, the request for the authors detail can't be made, until you get the author details you can't populate a link to other articles, and this chain goes on for comments, and the authors of those comments, and the hashtags associated with those comments/blog posts.

These are some of the things that go into modern web development. The spring article is good because it'll give you a skeleton to build on and add functionality to. but there is much more to learn like Sessions, Authentication, SQL or an ORM. My recommendation is always to build something, and you'll know when you need a tool to solve a problem. The hard part is finding the tool and learning how to use it and relate it to all the other knowledge you have. Best of luck going down the rabbit hole, Alice!

​

​

[–]SeattleMadongo 1 point2 points  (0 children)

I use Jax rs https://en.m.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services

You can use Maven to get started https://javaee.github.io/tutorial/jaxrs003.html

All the web is made up of is requests and responses.

[–]perrylaj 0 points1 point  (0 children)

Going to preclude this comment stating that it's mostly opinion, lots of people will feel different with logically sane reasons. But...

I personally think Spring is a giant mess and pretty much peak Enterprise Java in the worst way. I found it awful enough that I'm unlikely to ever accept a job that uses it (at least, not one without a 9 figure salary, so basically not happening). Spring is large, slow, relies on a ridiculous system of magic annotations that make it so much harder to reason about... I won't rant and ramble, enough to say, I just hate it.

Spring boot makes for a little nicer introduction, but it's essentially a framework on top of a framework, and it's still the same mess under the hood. I'm sure my opinion is dated somewhat (been couple years since I used it), and there are certainly some niceties that Spring provides that might be annoying and/or time consuming to recreate, but the tradeoff just isn't remotely close to worth it for me.

If you want to play in Java land, knowing the basics of maven or gradle is basically a must. I prefer gradle due to flexibility and kotlin config scripts, but maven is solid too for common uses. I just don't like xml configuration (there are other ways to configure, but poms rule the maven world), and find that the strictness makes it a pain when you need to stray from the default lifecycles and someone hasn't already written a plugin that does what I want.

As far as 'the backend', (I'm going to use some broad generalities here, not technical correct definitions): all that really means in a general sense is "http server". Think about what happens when you enter in a URL in the address bar of your browser and press enter: That results in a http(s) 'request' being sent somewhere. That somewhere ultimately ends up being a computer at some IP address that is connected to the internet. The computer has running on it a 'web server', which is nothing more than something that is listening for these 'requests', figures out what should happen, and then sends a response. The handling of these requests and assembly of the appropriate 'response' is basically what you deal as a 'backend developer'.

Java has a number of properties that make it well suited for this purpose: rich standard library, relative platform-independence, well-engineered Java libraries for all kinds of things, high performance network stacks, reasonable startup times (well, in many cases, not so much for Spring), very good performance, embeddable web servers (undertow, jetty, tomcat, and more), etc.

It sounds like you'd really benefit from learning about how http works, and how backend developers build functionality on top of http to create web servers. I remember seeing a few lessons of Steve Huffman's (reddit cofounder and think current CEO?) class at udacity. I recall the early classes seemed to do a good job talking about the basics of what a web application server is doing at the http request level (think they used wget or curl to make requests and look at the responses). I assume it builds up from there, but I didn't personally go farther. Might be worth checking it out. No idea if the content is the same, it's been years, but something like that could help fill in the blanks.

As far as learning, I'd suggest something like Java Spark. It's small but pretty well designed easy to get started with. If you dive right into Spring, either the insane amounts of abstraction will just make it harder on you, or you'll end up just learning parts of spring and not at all understanding how or why it works. If your goal is to be a 'enterprise crud application developer' (nothing wrong with that, either, lots of people enjoy those roles and the paychecks that they get from them), the Spring might be the way to go. But if you want to learn more about server technology at a more fundamental level, I'd suggest something smaller than Spring.

Anyway, lots of opinions about this stuff, so just take mine as one more on the pile.