DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. Frameworks
  4. Programming Without a Framework

Programming Without a Framework

Can you work as fast and efficiently with your own code instead of a framework? Experiments like this show that you can. Perhaps a better question is whether you should.

Grzegorz Ziemoński user avatar by
Grzegorz Ziemoński
·
Jul. 06, 17 · Opinion
Like (47)
Save
Tweet
Share
37.29K Views

Join the DZone community and get the full member experience.

Join For Free

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?

Framework

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • PostgreSQL: Bulk Loading Data With Node.js and Sequelize
  • Top Five Tools for AI-based Test Automation
  • A Real-Time Supply Chain Control Tower Powered by Kafka
  • The Quest for REST

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: