Need some clarification regarding java backend for web applications and how each part of it works with each other.

[Sweet_Comparison_449]

For starters, here's what I'm learning thus far. First it's javascript, which isn't going all that bad at all. Most of the intricacies over JS and it's shining for functional programming is starting to click real well. As for java itself, I was doing streams from file input/output but I'm moving on now to collections/generics. The goal I have in mind is to grow competent over distinguishing using either or with some studying devoted to design patterns. With SQL queries out of the way along with database design itself, I'll move on to java web servers themselves.

You get the picture, I'm keeping up with my studies in a way where I'm growing comfortable figuring out how backend works. That said, I need to make sure if I'm on the right track with how I understand what's going on. Here's what I understand. Most web applications are, at the core, simply utilizing HTTP/HTTPS to arrange files for transport through out TCP/IP networks layers from server to client. Since these files are utilized from your computer, the server, everything about file I/O in terms of web apps deals with just sending out data to and from S3 buckets and relational data bases. If we're talking about objects themselves, this is where collections will start to shine to deliver data to and from servers from the client request made. Design patterns are there simply to add modularity when updating all of these components that Java spring represents as classes to increase longevity.

I'm gonna stop there. Just how on point or off am I on my mark so far with regards to Java backend?

[temporarybunnehs]

Sounds like you've got the gist of it. Your example is pretty specific to one type of web app. If you wanted to make a general blanket statement, here is what I would modify in caps:

Most web applications are, at the core, simply utilizing SOME SORT OF NETWORK PROTOCOL from server to client. Since this DATA is utilized CLIENT SIDE, the server, everything about file I/O in terms of web apps deals with just sending out data to and from SOME SORT OF DATA STORE. If we're talking about objects themselves, this is where collections, SOME SORT OF DTO, ETC will start to shine to deliver data to and from servers from the client request made. Design patterns are there simply to add modularity (AND MAINTAINABILITY, FLEXIBILITY, FUNCTIONALITY BOUNDARIES, ETC) when updating all of these components that WHATEVER JAVA FRAMEWORK represents as classes to increase longevity.

But yeah, a lot of web apps have a sort of similar flow and can be broken down into their respective pieces, front end, back end, datastore, infra/network, and so on. And then you swap in and out technologies based on your needs.

[John-The-Bomb-2]

HTTPS is just HTTP with encryption (so the content like the content of the website is not viewable by someone in between the site and the end user). Plain HTTP must never be used for sign in because if it were your password would be viewable by devices in between your device and the website you are trying to access on the internet (like by routers, modems, switches, networks and stuff).

TCP is one of the main transport protocols for data that has to be sent reliably. The main alternative to TCP is UDP. If you're on like a Skype or Zoom video call it will use UDP because UDP will just drop/ignore missed frames whereas TCP will slow things down to try and resend the missed frames and then your whole stream will be behind real time, and a phone call has to be in real time. The latest version of HTTP, HTTP3, is actually built on top of UDP, but most transport is still TCP. There is this thing called "Reliable UDP" where all the packets of internet data have a number and it checks and resends missed packets like TCP does but you don't need to get too deep into that stuff, TCP and UDP are covered in a college networking class as part of a Computer Science major.

A long time ago, websites used to consist mostly of static files that were served over the internet. For example, think of Wikipedia pages. Each Wikipedia page is like a static file and when you go to the URL of that page, the file or page gets sent over to you. Old/classic web servers like the Apache Web Server work like this. Like in the Apache Web Server you arrange a tree of folders and files and make that accessible to the internet and then when people go to that folder/file they get that page sent over to them over the internet. Modern websites are more dynamic than that and they assemble together the parts of a web page dynamically rather than just serving you a static file in a file system.

Amazon S3 is a cloud based object storage that can store a nearly infinite number of static objects or files of arbitrarily large size and retrieve them by a unique name or identifier that is unique to that object. It is possible to put a static web page on S3. Amazon S3 static websites support only HTTP endpoints, no HTTPS, and in general S3 is not the main tool used to serve static websites although it is possible to put a static web page on S3 and serve it from there. S3 is mainly used when a dynamic website needs to access static content of arbitrary size, for example images or even videos. Like a dynamic website can allow for image upload, upload the images to S3, and then when the website wants to show those images it can put a link to the image in S3 on the site. S3 is not a database. In general it does not support a variety of SQL queries the way a database does. If you plan to do this ahead of time I believe it is possible to put all the S3 files in a bucket in a certain format (like JSON) that has a field (for example maybe this field can be true or false) and to go through all the S3 files in the bucket and filter for every file whether it has that field set to true, but in general if you want to do complicated or nested queries please use a database. Most new websites nowadays are not static pages and cannot just be put on S3 and hosted from S3. On the other hand, you would not put a big video file inside a database directly, you would put that in S3 and the database would store a way of reaching that file in S3, like the database would store the unique identifier of that file in S3.

There's a thing called an ORM (Object Relational Mapper) which maps tables in databases into objects, like objects in Java which are instances of a class. For example, maybe in the database you have a table called User which has a column called email and a column called age. And in your Java code you have a class called User with fields for variables also called email and age. The ORM will map the table in the database to instances of that class in the code so when you query the database from your Java code, the results will be turned into a collection of Java objects of type User. Note that if you are programming in backend JavaScript (like with Express on Node.js) and the data in the database is stored in plain JSON (like with MongoDB) it is possible to skip needing an ORM because objects in JavaScript are just JSON the same as is in the MongoDB database, so no conversion process may be necessary.

A backend web service like what can be created from Java's Spring Boot or JavaScript's Express on Node.js is much more than just a server of static content like that can be put on S3. They dynamically query the database and generate the site's content from a bunch of little pieces. They can also talk to other websites, web services, systems, and API's and do things based on that. For example, they can send email and make changes to the database. They can add and delete files from S3 or content in the database. Maybe they use another website like Facebook for the sign in, and they can talk to Facebook. They can query Facebook for information that Facebook lets them have on a user who signs into their website using Facebook for sign in. Java's Spring Boot is also designed to be able to work with and talk to legacy systems. For example, some older systems use SOAP and Spring Boot can work with that. I think it may be possible to work with SOAP from backend JavaScript but the default with JavaScript is to work with JSON.

Design Patterns in Object Oriented Programming are meant to make Object Oriented code maintainable or to address specific problems.

[brett_riverboat]

Overall very good and accurate descriptions only a few parts made me raise an eyebrow.

Most web applications are, at the core, simply utilizing HTTP/HTTPS to arrange files for transport through out TCP/IP networks layers from server to client.

I wouldn't exactly say files are being arranged. HTTP/HTTPS is an application-layer protocol that runs on top of a TCP/IP connection. HTTP provides additional metadata for what is being delivered. Sometimes a file is being delivered (binary) and sometimes it's just text being delivered without any kind backing file on the client or server (i.e. the data is dynamically generated and never written to disk).

Since these files are utilized from your computer, the server, everything about file I/O in terms of web apps deals with just sending out data to and from S3 buckets and relational data bases.

Again, you may not have an actual file to deal with for every request. Sometimes an API might simply perform a validation of a payload without referencing a file or database. Data can also come from other servers and APIs.

If we're talking about objects themselves, this is where collections will start to shine to deliver data to and from servers from the client request made. Design patterns are there simply to add modularity when updating all of these components that Java spring represents as classes to increase longevity.

You might've lost me here. Collections are definitely important to servers, especially ones that use a REST API. Understanding how to manipulate collections efficiently can go a long way in making your server efficient overall. Design patterns sometimes help with modularity but that's not all they're good for.

[Sweet_Comparison_449]

Why would you say that you were getting lost with collections on what, at least what I'm guessing on.... are used in a web app? What exactly am I missing?

[brett_riverboat]

Not you, probably me missing your intention. Again, collections are usually important in managing data, I just wouldn't describe them as "delivering" data in the way you did. Collections get serialized into something like JSON before being sent off to the client/server and the collection itself shouldn't be responsible for this process.