Hey everyone! I've been using Kotlin for a year no...

# getting-started

[Miguel]

Hey everyone!
I've been using Kotlin for a year now, mostly in the backend and some Android.
I've recently created a WebApp with Kotlin + Ktor framework, and discovered a different way of loading/presenting HTML, using FreeMarker.
I've created my WebApp following a guide, this one!

I am now trying to explain what was done to some of my peers and I encountered a problem..

Imagine you have the following routes available in your API (server):
• /home
• /projects
When the browser hits those routes, the server application has some logic that needs to be executed, after processing what it needs, the server answer the browser with an HTML template through the use of FreeMarker.
My question to you is where is the client in all of this?

In a "normal" full stack web app I was expecting to see a clear separation between Client and Server.
Something of the sorts of:
1. Browser makes a request.
2. Client receives it, does some validation
3. Sends the request to the server
4. Server processes/retrieves data
5. Server answers the client (a JSON for example)
6. Client receives the JSON and builds/fills an HTML page with the data.
7. The browser loads the different HTML.
!! This is an oversimplification of things, but I think it can convey the idea of what I was expecting versus the reality !!
This is the reality:

1. Browser makes a request.
2. Server app receives and processes it
3. Answers the browser with an HTML page, via FreeMarker.
Code snippet retrieved from the guide I linked above:

fun main(args: Array<String>): Unit = io.ktor.server.netty.EngineMain.main(args)

fun Application.module() {
    install(FreeMarker) {
        templateLoader = ClassTemplateLoader(this::class.java.classLoader, "templates")
        outputFormat = HTMLOutputFormat.INSTANCE
    }
    routing {
        static("/static") {
            resources("files")
        }
        get("/") {
            call.respond(FreeMarkerContent("index.ftl", mapOf("entries" to blogEntries), ""))
        }

Is it safe to say there's no client? Is that even a thing?
Sorry for the long format, I'm a bit confused, if after reading this you are too, I can clarify it further.

[hfhbd]

You are talking about two different architectures:
- "Old" architecture processing and rendering the HTML on the server. This architecture is moves mostly all logic to the server. If you access some external services from the server, the HTML answer has to wait. This leads into a slow HTML response and a bad UX.
- "modern" architecture sending a static HML (ideally using a html file with proper cache headers) from your server and split the logic between client and server. During a request, the client logic shows a proper waiting screen to the user (or better, do the requests in the background), while waiting for the new data (no HTML)

[Miguel]

Thanks Philip!
I take the "old" architecture is the one that uses FreeMarket right, because all the logic is within the server.
Browser<->Server

The "modern" one is then what I was expecting to see, right?
Browser<->Client<->Server

At the moment I cant change from one to the other. I am just trying to understand what have I built, in order to explain it and improve it in the future.

[tddmonkey]

What you have is “server side rendering”

[Miguel]

Okay, makes sense yes.
Is this something good, or to avoid?

And with this type of rendering I dont have a client right?

It's a bit weird I cant find good info on the guide about this.. I suppose this is at least a correct way of doing things, if it wasn't it shouldn't be on an official guide :s

[hfhbd]

@Miguel I would recommend this book explaining the history and the modern development of web apps. https://www.amazon.com/Modern-Web-Development-WebSphere-Multi-Platform/dp/0133067033
Don't be afraid about the used web server (WebSphere), the architecture is the same.

[Miguel]

@hfhbd Thank you, already added this to a bookmark. I really want to know more about this, but for a presenattion that has to be made tomorrow I dont think I can read the book and form a quick analysis about what was presented in it, bridging the concepts learned and what I did in my Web App.

From your perspective (the community of people that know much more than me), what do you think is happening here?

@tddmonkey already told me this is server side rendering, from which I take there's no client side involved in this web app. But @hfhbd already told me that this is dangerous and can lead to a slow UI and a bad user experience, which makes total sense.

So can we conclude that this is a bad way of doing things and should not be in an official guide? Or is there a time and place for something like this?

My own web app is simple, purely navigation. The only required action is for the user to insert some data, a simple form with 3 fields, that data is then processed by the server, that generates a QR code and presents it within the browser.

Is this "old" approach, that has no client, renders and processes everything within the server an okay path for this simple web app?

[tddmonkey]

If it works for you, it’s ok for it

[Miguel]

Thank you all for the help, I concluded that between this 2 ways that I know, this is just another possible way forward.

If it is the best or not I cant reach that conclusion with my current knowledge. I will research this topic further and maybe one day a conclusion can be reached, if nothing else at least that it depends on the use case.

Once again, thank you!

[corneil]

Rich client are huge on initial download. If you have a server-side rendered page but use some front-end logic to update selected data you can provide a light page with pretty good user experience. Not all users are on the other side of broadband fibre.

[tddmonkey]

“If it is the best or not I cant reach that conclusion” - what’s best for one situation might not be for another one. Like you’ve said, this is just another way of solving the problem. This approach has definitely fallen out of fashion and has a bunch of disadvantages - but like you’ve discovered, it’s definitely useful in some places.