(Some posts I make for my future self. This is one of those.)

TL;DR: To host a nextjs on S3 through a custom domain do the following

• Register domain on Route 53
• Request certificate through ACM
• Create S3 bucket
• Enable trailingSlash in nextjs in next.config.js
• Export nextjs app as static (next build && next export)
• Upload static content to bucket
• Enable static website on bucket and set Index Document to index.html
• Configure distribution on Cloudfront to distribute the S3 static website domain (not the S3 bucket ARN)
• Use the domain name registered through Route 53 and choose the certificate from ACM
• (If the certificate dropdown is empty or do not list the certificate for your domain, it is not available yet and you have to wait up to 24h)
• ...
• Profit

I often make prototype web sites or web apps to try out an idea. My weapon of choice these days is nextjs, which is a a quick way of getting started on building a web site in react. nextjs sets everything up to enable server side rendering and routing. Routing is done through files, so that a file in /pages/about.js is available as /about. It makes development easy.

To move the app from localhost to generally available to allow for feedback, I like the simplicity of hosting it on Amazon S3. To host a nextjs app, I therefore export it to static files, using next build && next export. When exporting static from nextjs, it will generate html-files that will be the entry points for the site. By default, a page like /pages/about.js will create the file about.html. Once exported, the page will load about.html, but linking to other pages (e.g. /products) will use react to update the page rather than reloading the web page.

To host the web site, one can simply upload the exported files to an S3 bucket, and use the bucket-domain-url to share the app (by making the files public), or enable S3 static website. The main difference between these two ways of accessing the content of the S3 bucket through a web browser, is how it handles folders. When accessing https://bucket-doman/folder/ it will list the content of the folder (if such access is granted on the bucket). However accessing https://bucket-website-endpoint/folder/ will try and serve the file index.html in the folder. While it is possible to configure an S3 bucket to serve index.html in the root directory, it is not possible to set index.html as the default file of any folder. Only static web site enables that. This will come in handy when enabling a custom domain.

Once the app is made available on an S3 static website as https://my-bucket.s3-website.eu-north-1.amazonaws.com, you might want to use a custom domain name for anything beyond an early prototype. There are two options for this: use another bucket as a domain-bucket and redirect to your website-content-bucket, or use Cloudfront. I will use Cloudfront, and register a domain using Route 53. Using Route 53 for domain names makes things easier, such as getting certificates.

Register the domain using Route 53. Then setup custom domain hosting using Cloudfront, by simply creating a new distribution in the Cloudfront console on AWS. As Origin Domain Name use the S3 bucket static website domain (do *NOT* use the bucket name as suggested by the console). Under Alternate Domain Names type your custom domain as registered through Route 53. Since you do not have a certificate yet probably, click Request or import certificate with ACM (Amazon Certificate Manager). Once you've created the certificate, be prepared to wait 24h before it becomes available in Cloudfront... Didn't say this would be fast. Once the certificate is available in Cloudfront, select the certificate in the drop down list (if there is no dropdown list, there is no certificate available yet). You now all set.

You will now have the nextjs static website hosted on S3 through your custom domain.

Finally, you will notice that if you browse from e.g. index.html using a link in your app to e.g. /about, and try to reload the page, you will get a 404. This is because the url is /about, but there is no S3 object with this name. Instead there is a file called about.html. So how do we fix this? The most trivial way is to make sure nextjs exports about as a folder with an index.html file in it. You can that by adding a next.config.js file where you set trailingSlash: true. Now all of a sudden everything will work as expected on your new custom domain.

If you accidentally do not choose to distribute the static website domain through Cloudfront, but instead pick the S3 bucket (an honest mistake), you can no longer host /about/index.html through the url /about/. This, it won't work. The fix is to enable static website on the S3 bucket, and to distribute the static website domain rather than the bucket through the bucket ARN in Cloudfront.

Last semester I gave a course on mobile app development using Flutter. The course was based around a series of video lectures, exercises, and supervision. Since the videos are recorded and there is not that much material on Flutter in Swedish, I decided to upload them to YouTube.

They are available here

The series of videos goes from introduction to Flutter, introduction to Dart programming, basic UI layouts, more advanced layouts, state management using StatefulWidget and Provider, and finally network communication.

Essentially it covers the basics of all aspects needed to build simple mobile applications.

I've been meaning to add the possibility to control the AC in my car from Google Home for a while but never got around to it. A few nights ago a finally set to action.

Google Home is basically Google's take on the smart home. It is an ecosystem of things. The google home smart speaker is integrated with the google home app which is integrated with the google voice assistant, etc. etc.. In the Google Home app, you can setup devices you have around the house that are compatible, such as lights, power outlets, thermostats, etc. Once they are setup in the app, you can control them using google assistant or google home smart speakers. So, if I want to turn to be able to turn on the AC in my car by saying "Ok Google, turn on car AC", I must make sure I can have a device in google home with the name "car AC" and when I issue the command "turn on", it will send a signal to my car to turn the AC on. To do that I started looking at Actions on Google.

(Do I really need to build something for this? No, there are a couple of actions on google integrations already that you can simply add. However, when you do, you basically give away all control of your car to a third party. With this control and physical access to the car, you can essentially walk up to the car, unlock it, and drive away. Now, I'm not too paranoid about this, even though I probably should be. But, in this case, instead of giving someone the chance to drive away with my car, I much rather learn how to build this myself. After all, it's really quite easy.)

Actions on Google allow you to "integrate with google assistant". This currently means that you can extend your mobile apps to work with the voice assistant, to create conversational apps (basically apps that you use through voice/text... yes, chat bots), or connect to smart devices (i.e. google home). For my purposes, I do not want to create a conversational app. If I did, I would have to say things like "Ok google, talk to my car. -Ok, talking to your car. -Hi I'm your car what can i do for you? -Turn on AC. -Ok, AC turning on". Zzz. I much rather just open the app on my phone and press the climate button. So, instead I went for smart device integration.

Actions on Google for smart home devices is really quite simple. You need an Oauth server that can issue a token, and an https endpoint that respond to commands issued by the google assistant. We are simply building a service that acts as a server for a particular device type. There are only four commands possible: Sync, Query, Execute, and Disconnect. WIth an access token received from your Oauth server, the Sync command should respond with a list of devices that this user possesses. Query should respond with the state of the queried devices. Execute should abide to whatever the particular command is (e.g. TurnOn should turn on the device), and Disconnect should do what ever needs to be done whenever the user unlinks their google home with your service.

So I first implemented the Oauth server. There are essentially two routes required: auth and token. The auth route should let a user authorize themselves and tell Google that it is ok for your service to share access to their devices. The server responds to google through a redirect route including an authorization code. The token route should take an authorization code and return an access token (as well as a refresh token that can be used to refresh the access token). For more information go here.

In my case I let a user authenticate with their tesla account, and use their access token as the access token (together with some other stuff). This means I never have to bother storing any information on my server, but let Google store that in the token instead.

Next, the action route. Google issues POST requests to the route with access token in an Authorization header. The post data is JSON and includes a requestId and a list of intents. The intent specifies if it is Sync, Query, Execute or Disconnect.

Sync does not send any additional data, but simply expects to have the devices associated with the user returned. For this, I lookup the devices associated with the tesla account (as given by the access token) and return the device data mapped to data expected by Google, including an id that can be used to identify the device when issuing commands to the Tesla API in the future. For each device Google also expects the type of device, and its traits. The device type is not really important as far as i can tell although it will dictate what it looks like in the Google Home app. But the traits specify what commands can be sent by google assistant. In my case I want to be able to the the heat on or off, so I picked the device type action.devices.types.HEATER (CAR doesn't exist as a type), and the trait is actions.devices.traits.OnOff.

For Query, Google sends a list of devices it wants the status of. Here I simply iterate through the list, and fetch the status of the climate of each device. (The Tesla API has four distinct states fetched through four different routes: climate, drive, vehicle, and charge.) With a device trait of OnOff, Google expects a state named on to be true or false. I set it to true of the climate is on.

Finally, (I don't bother with Disconnect as there is nothing to do), I implement Execute. Execute is a bit of a handful as it will send a list of commands as a set of devices and executions. Here I cheat majorly and assume there will be only one command, with one device, and one execution. The execution of action.devices.commands.OnOff carries a parameter of on that is set to on when the command is to turn the device on. Depending on this value I either turn the climate on or off through the Tesla API. Finally, Google expects you to respond with the final status of the commands for each device.

Finally, when setting up the Action on the Actions on Google Console, you simply add the auth and token routes for your Oauth server, and the action route for your Action. When complete, hitting test will set the action up for you to use through your own google assistant only.

All in all, there are a few concepts required to learn around Actions on Google, but once you understand those, enabling you to control something through google assistant is really as simple as writing a small rest API. Next I might add more capabilities, such as adding both the car heater, and the car charger, so that I can start or stop charging at home. I might also add the capability to set the temperature I want in my car, although I very rarely change this so it's very far down my todo list.

And here's the code.

After a little more than two years at Iteam, I am now back in academia! This week I'm starting my position as a senior lecturer at the University of Gothenburg. I will be affiliated with the division of human-computer interaction at the department of applied IT. The division is just starting as I join, so I will be working together with Alexandra Weilenmann to establish it.

I am currently interested in understanding how mobile technology (and IT in general) is affecting our well-being (both positive and negative), and will continue looking in that direction. I'm also very keen on collaborating on this with other researchers, across disciplines so please reach out if you find this topic interesting.

I am excited about being back as an academic, both to do research and to teach and inspire students.

Quite often I need to try a simple idea for a new service or app. My weapon of choice is currently nodejs and react. It is fairly easy to quickly hash out a server backend. Using create-react-app or NextJS, it is also quite easy to write a react frontend for said backend.

This is all nice and well for a bit while you try out the idea for yourself. But no idea is really worth anything until it is shared with others. So now you need to host both the frontend and backend somehow, and point the frontend at the backend. This typically involves too many steps to make it feasible to try out the very simplest ideas.

What I typically want, is a single server that can run somewhere that hosts both the backend and the frontend. Ideally just a Dockerimage. And I want this to just work without bothering with builds and such. After having done this for a few projects recently I decided to create a template so that I can reuse it whenever I need to try out the next idea.

The result is in this GitHub repo.

To use it, copy the repo. Run npm install and then npm run dev. (I use node 10 and there is a .nvmrc in the repo.)

You now have a server on port 3000 that will restart when you change the server files, and will rebuild the client when you change the frontend. You are basically set to start materialising your idea.

Once you want to share it, you can either use ngrok, or build a Dockerimage using the Dockerfile in the repo and host where you typically host things. When the image starts it will build the frontend. I do it this way instead of when the dockerimage is built so that we can set environment variables on the hosting platform easier.

The repo sets up webpack 4, babel 7, react, express, and jest. The server runs in development mode or production mode. In development mode the server restarts when the backend code changes, and rebuilds the frontend using webpack on client code changes. In production mode the server builds the frontend on startup. It is called production mode, but I would not recommend this for actual production ready applications. But for a PoC this works very well.

Feel free to open issues or send PRs on the github repo.