Application Development Meanderings

programming languages, not sure javascript's ES* all make sense Well I was just thinking the other day about javascript and its pros and cons. Its clearly an interpreted language with a simple syntax. That makes it easy to learn. However, there have been alot of changes using the ES* process. Each version adds some new functionality, sometimes a little sometimes alot. Sometimes just enhancing a few APIs sometimes making large changes, such as adding module systems. I was doing some work in scala.js the other day, along with nodejs+express+mssql+typescript for the backend. I could have written the backend in scala.jvm but there was no compelling reason to do that as there was some json manipulation and I find js to be easier to use when json is involved. You can avoid alot of encoders/decoder type coding when using scala.js and that just makes it much easier (whether you are in scala.js or typescript). But I did notice that even with instant node+express rel...

env variables with node, express and typescript If you need to manage environment variables better for express, node and typescript web services, you have a few choices. Define a default set of vars using an “environments” file and fallback to those while using an optional user provided file. Add fallback values in .ts code. Don’t add fallback values and error out of require variables are missing. The standard thinking is that if you have environment variables that hold secrets or a file of environment variables these should not be checked in at all because you should use the production method of setting environment variables e.g. a container can set environment variables using container methods. You can always setup a separate, restricted VCS repo to hold secrete information that only production admins can access. Hence, .env files should only be used for non-production, say dev and test, and not checked into VSC. The default package to use is “dotenv”. dot...

typescript, node, express: adding ts properties to Request If you use typescript with node+express and you add some context to the Request parameters, you need to adjust your Request type to reflect the additional properties. Otherwise, your IDE may flag any accesses to these properties as errors. Let’s assume you will add an “environment” property to Request. You’ll want to have that property available to typescript. I always have a types folder sitting around in my “src” directory that has a types.d.ts file. You do not need to put this into a type roots folder and change tsconfig.json. Here’s my adjusment: import { Request , Response , Send } from "express" import * as env from "../interfaces/Environment" // add our addition to Request declare global { namespace Express { interface Request { environment : env . Environment } interface Response { // holds original Response.sense, used...