Programming Without a Framework

I've recently been working on a nice project that was small enough to make me feel free to experiment and, on the other hand, big enough to validate my ideas and see how they scale. One of the experiments that I've conducted throughout the project was, can I do it without using any major framework? Is this going to take more time? Is it going to be considerably harder?

The Approach

Obviously, the ideas presented here are nothing new and quite a few people consider it the right way to do software. Therefore, if you're familiar with the notions of dependency inversion or using many small libraries instead of one big framework, this section won't be very enlightening.

As I already hinted in the previous paragraph, I decided to rely heavily on the Dependency Inversion Principle, so that whatever extra "infrastructure" code I produced in the process is what I'd adjust to my needs, not the other way around.

To be more specific, for any kind of code that would "normally" be provided by a framework, I started with an interface that describes my actual, current needs at that moment. Once the interface design was complete, I implemented it in the infrastructure layer of my application. Essentially, I went into a loop of inventing some kind of "API of my dreams" for a given problem and then provided myself with exactly that.

package stupid.jokes;

interface Dreamable {
  Lots<Money> makeHappy(Customer customer);
}

Since I had a hard deadline on the project, I treated the interfaces as a kind of fallback scheme in case of timeline issues. If anything wrong was to happen, I could try to bring in some heavy artillery (i.e. Spring) and implement the interfaces with that.

As long as there were no issues with the timeline or my low-level programming skills, I decided to stick with using (relatively) small libraries and coding some of the important chunks myself.

Example: REST Endpoints

I guess that the code for exposing a REST endpoint is a pretty good example of functionality that would normally be provided by a framework like Spring, Ratpack or the like. I also think it's a good example for this post, as cool ways of defining endpoints are supposedly an important thing when choosing a framework.

My "dream API" in this case was pretty simple. It required the infrastructure layer to implement two interfaces and defined two extra type aliases (we're in the Kotlin world):

interface Router {
    fun get(path: String, action: Handler)
    fun post(path: String, action: Handler)
    fun put(path: String, action: Handler)
    fun delete(path: String, action: Handler)
}

interface Request {
    fun body(): String
    fun <T : Any> body(clazz: KClass<T>): T
    fun pathParam(name: String): String
    fun queryParam(name: String): String
}

typealias Response = (Any) -> Unit

typealias Handler = (Request, Response) -> Unit

Obviously, I didn't write all this at once. I iterated over it feature by feature, method by method. If I remember correctly, my first endpoint required just the "post" support and a request body.

During application startup, an instance of the Router implementation is passed onto a method responsible for initializing all the routes in the application:

fun init(router: Router) {
    router.get("/groups/:id/members") { req, res ->
        val groupId = req.pathParam("id")
        val members = findMembers(groupId)
        res.invoke(members)
    }

    router.post("/groups/:id/members") { req, _ ->
        val groupId = req.pathParam("id")
        val studentToAdd = req.body(StudentToAdd::class)
        addMember(groupId, studentToAdd)
    }

    router.get("/groups/:id/lessons") { req, res ->
        val groupId = req.pathParam("id")
        val lessons = findLessons(groupId)
        res.invoke(lessons)
    }

    router.post("/groups/:id/lessons") { req, _ ->
        val groupId = req.pathParam("id")
        val lessonToAdd = req.body(LessonToAdd::class)
        addLesson(groupId, lessonToAdd)
    }

    // etc.
}

Your opinion might differ here, but I really think this is a nice piece of API. What's most important here is that it does everything I needed for the particular use cases of this application.

Now, I don't really want to show the whole implementation here for a few good reasons, but I'd like you to know that it's much simpler than many people think.

For instance, a simple mechanism for handling path parameters using the Servlet API is a matter of splitting Strings and looping over URI parts:

fun parse(req: HttpServletRequest): Request {
    val uriParts = req.requestURI.split("/")
    val pathParts = path.split("/")

    val pathParams = mutableMapOf<String, String>()
    for (i in pathParts.indices) {
        if (pathParts[i].startsWith(":")) {
            val key = pathParts[i].replace(":", "")
            pathParams.put(key, uriParts[i])
        }
    }

    return ParsedRequest(req, pathParams)
}

Another good example connected with exposing REST endpoints from your application is starting an embedded web server. Some people are so happy that frameworks like Spring Boot have this functionality out of the box even though starting the server by yourself is actually a piece of cake:

fun main(args: Array<String>) {
    val server = Server(8080)
    server.handler = HandlerList(routerServletHandler())
    server.start()
    server.join()
}

private fun routerServletHandler(): ServletHandler {
    val servletHandler = ServletHandler()
    servletHandler.addServletWithMapping(RouterServlet::class.java, "/*")
    return servletHandler
}

Results

I'm glad to report that my little experiment was successful and the application was delivered on time without using any major frameworks. I'm also glad to report that writing applications this way is not a struggle. On the contrary, I had a lot of fun and I didn't feel like I was going much slower than using some of the popular frameworks.

Fun aside, I'm not sure whether there's any important lesson learned during this experiment. One side of me keeps asking me why do we, developers, blindly follow the framework hype when there's not that much benefit to it (if any). On the other hand, is there any point in reinventing the wheel every single project that we start, especially in the world of microservices where there's so many of them?