On September 5th 2019 I was able to give my first live seminar for Jaxer hosted by OSSAJ. This was my first time presenting for an what was supposed to be an hour long seminar. In terms of presentation style I think the most important aspect is to relax, and I think I was able to do that better during the Q&A session.

The other aspects to improve on is that my Japanese has actually gotten progressively worse while living in the country over the last ten years. So I should probably either mix in some Enligsh or spending more time to prepare verbally for a presentation. And then on the recording side of things, the video is going in and out of focus and there is a lot of noise in the audio. So what I might do is set up a cell phone on a tripod and then use my Yeti microphone to try and capture the sound.

For the presentation itself I tried to pick something that exists that is the closest representation of how Jaxer is structured. And I chose AWS server-less design approach. I think people like to use the server-less approach is it means that more time can be focused into client development, as authentication is managed before getting through the application, and data manipulation takes place via what are client API’s. So the developer doesn’t have to think about programming on the client, writing an Ajax request, writing application to handle the request, make a query with the database, return the request and then update the client UI.

And while the approach is simple, it’s because a lot of infrastructure is in place for the developers to work on one specific application of implementation. When writing an application from scratch there are going to be changes to the data structure, rewrites, and a certain amount of trial and error that takes place before the vision of the application starts to take shape and reach a stable end-user version.

It’s this development cycle where Jaxer really shines. You can declare scripts to be runat the server or as a server-proxy, and Jaxer will automatically create server callbacks for functions that are defined as server-proxy. When the server-proxy functions are called, Jaxer will take the arguments, parse them into a JSON string, send the JSON string to the server, parse the JSON, resolve which function needs to be called, pass the arguments into the function, and then take the return value, serialize it to JSON, return it to the client, and then return that value from the client function.

The whole process isn’t dramatically different from the flow of other server-side languages as the fundamentals of http-requests still apply to all of them. The difference is that it does these functions in a way that makes provides a seamless programming environment between the client and the server. You can write a client function that calls the server, and then write a function that queries data from the database, returns it and then continue writing code like nothing ever happened.

In comparison to even a simple language like PHP, where if you need to get information from the server, you will need to write an Ajax request, and then decide how you will send the information to the server. Then even for a simple language, you will have to change the syntax and thinking to server code to interact with the database, return the value, parse the value on the client, and then decide on how you want to handle it. For people who write code like this a lot it’s likely separate nature, or for companies who separate front-end and back-end it might not be too much of a consideration.

But in practical application environment that Jaxer provides makes full-stack development much faster for small teams as you do not have to change gears when writing. You write on the client, you write on the server and then you’re back on the client again. And if you need to change something, you can edit the various functions using extremely similar Javascript syntax, you reload the page and you can continue working. So it’s a really robust approach that reacts to changes quickly, and as an added side bonus, because Jaxer parses the scripts when the page is reloaded, it makes it more difficult for the client and server to become de-synced with the data they are expected to receive.

The full seminar is an hour long. So I will be splitting off the Q&A section into its own thirty minute video and I will upload that, and provide background commentary it its own blog post.