You can listen to the podcast and read the show notes here
Michael Smith: Welcome back to the show. I'm here with Nathan Francis. We're going to be talking about the best REST you ever had. That's not a nap. That's rest as in ColdBox REST. We'll also be looking why you might want to use REST instead of doing regular ColdFusion and why ColdBox is the best REST. Nathan has used a whole slew of different REST APIs. He's got a lot of experience there.
We'll also look at how, if you need to convert between REST APIs, or convert from regular ColdFusion code to REST, how easy it is to do that. Also, we'll look at a cool project he's been working on using REST and Couchbase, which is a really light weight setup he's got. Welcome, Nathan.
Nathaniel F.: Thank you, sir. Glad to be here with you.
Michael Smith: I think we better start with the big question in the room, which is why should anyone use REST instead of regular ColdFusion? A lot of CF developers don't even use REST.
Nathaniel F.: Yeah, that's very true. I think part of that comes from CFML's heritage itself, which CFML excelled. It was one of the main languages that excelled at making just full bodied applications dynamically. Since it thrived in that area, when the tech industry moved to some newer ideas, it had a good sweet spot.
ColdBox has allowed CFML to really move forward. One of those ways is with REST APIs. What that provides is instead of these full bodied, traditional applications, you can make something that anything can touch. You can use any type of front end technological mobile obviously is universal now, even things all the way down to the watches and the Internet of things to be able to talk to a REST API.
That really makes your program universal. That bounds to the traditional sweet spot that CFML has traditionally been in. REST APIs are versatile. That means when you write something, you know it can reach a lot farther than just the browser that it used to.
Michael Smith: If you wanted to swap out a different front end, that would be really easy to do?
Nathaniel F.: Yes, absolutely. It'd be very easy to do. What that does is it makes both ends of your application able to go through phases. If you wanted to freshen up your front end, your back end is solid with the REST API setup. You can even your REST API itself to have updates to it, completely independent of the front end.
Michael Smith: It separates out the different pieces of code, gives you more versatility in how you deploy the app.
Nathaniel F.: Yes, absolutely. That is probably the cleanest way of doing it. Separation of concerns is good on development teams as well. Whereas we like to talk about being full developers and knowing everything from being a sysadmin and a database expert, to a backend data modeling expert, to doing cool things in the browser, the truth of the matter is people are really good at certain things.
I, myself, am familiar with most of those areas, but I find that I excel at certain ones. Having a team and you can separate those concerns and say, “Hey, you guys are really good at this front end, you do that and you hook it up to this back end and we can work on this back end.” It makes things work together very smoothly, so it's better for teams.
Michael Smith: Yeah. Is this similar to MVC, or other design patterns where you separate out the model from the view? Or, is it taking it a step further?
Nathaniel F.: I think it takes it the step further. You'd apply MVC patterns to both parts. I think what this does is it disconnects the responsibilities of dealing with the data modeling and the database itself from that front end. The front end just connects with the REST end points to get what it needs.
For the back end, it doesn't have to worry about maintaining the state of the views, because the REST API itself is very stateless. It just pulls away some of those things around the edges and lets each part. It's good.
Michael Smith: Does doing things in REST add a lot of overhead to your app, or?
Nathaniel F.: I actually think it simplifies it. The REST API portion, itself, is obviously more simple than doing the full app. I think being able to focus on just that area actually makes it much cleaner and simpler.
Obviously, having a front end and a distinct back end, it sounds like a much larger thing, but with the plethora of different ways they're deploying front ends these days, I think having a REST API back end gives you something to ease the mind of the presentation and lets that be its own animal, so to speak. It works better in the end.
Michael Smith: You've programmed in a lot of different REST APIs. You mentioned earlier Adobe ColdFusion, CFWheels, Node, other ones. Why do you prefer the ColdBox one?
Nathaniel F.: I prefer ColdBox; full disclosure here. ColdBox has been a comfort zone for me for one. I need to be honest about that. Some of the key clients and key projects that I've been able to work on professionally have been fortunate enough to be built on ColdBox.
I have worked with other clients that have used a variety of strategies in doing CFML with REST APIs. I also have done a few presentations before on REST for the CFML community. I've looked a bit wider even than I've used. I've looked at how each of the different known frameworks used it.
The more I looked at it and the more I compared them, I think there's a lot of advantages and different ways of doing it. ColdBox keeps it simple, where I think it's right to keep it simple. It also maintains a lot of extensibility and a lot of capability there that some of the other solutions don't do.
I think, in defense of the native Adobe ColdFusion and if you were to do this natively in Lucy, I think it's worth defending that anything that's native tends to be just a little more garbled. Frameworks are designed. ColdBox is designed to make the hard things simple and give you the ability to do what you want to do without a lot of overhead. It does very well at that.
I would say, of all the solutions I've seen, and I'm not going to name a bunch of them, because I think they do a good job at what they do. I found that ColdBox excelled at meeting capability, extensibility, and simplicity and allowing people to get done what they need to do.
Michael Smith: If someone has code that's doing REST, but it's in another API, is it a really hard task to move it to the ColdBox REST API?
Nathaniel F.: I think we run in the same discussion if we were going to talk about any legacy app. I think what that is is you got to find the parts that translate well. ColdBox makes the REST specific aspects of dealing with things like the HTTP verbs, the status cards, and the routing straight forward enough that any of the other systems can translate well.
You're looking at a similar discussion if we were to convert any legacy ColdFusion app into ColdBox. There's always going to be different complications here and there, but did a really good job of trying to make it as simple as possible.
Michael Smith: Speaking of legacy ColdFusion code, if someone wanted to change that over to use the REST architecture, how is that to do? Is that pretty easy, or hard?
Nathaniel F.: We've taken even a full bodied ColdBox app and done that with it. The process would be very simple. You're looking at two things with a full legacy non-ColdBox step. One, is getting the legacy app into ColdBox and getting it working, which there's some great resources on that. There's some people that have done some fantastic talks on that. It's surprisingly easier than people think.
Step two would be turning that traditional now working, ColdBox, full bodied app into a REST architecture. That would be taking the views and moving those out into a completely separate application that would speak to the REST, then using all of your business logic and event handling, and data modeling as your REST API, a completely separate unit.
It's two steps. I would definitely choose to get it ColdBox-ified first, which isn't that bad. From there, start splitting those separation of concerns out, getting the whole view presentation that the user interacts with into a lightweight app of your choice and then moving all of your logic into a REST API. We've done that.
Michael Smith: Mm-hmm (affirmative). You mentioned you've got the separation from the data in the front end. Are there any other advantages to doing that kind of migration?
Nathaniel F.: Some of it can be hosting. It depends upon really which presentation strategy you want to use. I'm of the opinion that if you're targeting a mobile audience of any kind, that REST is really going to give you advantages. That disconnection of not absolutely requiring that full body connection allows you to take advantage of things on the mobile device that we weren't able to really capitalize on previously.
It allows you to get what you need and then maintain whatever state your device needs otherwise. That's becoming more and more prevalent. I would say now I know of two recent projects that we just did in our company. We approached mobile first. That's a brain spinner to do. We all think we develop on a desktop, or a laptop. People still use these.
We came into some legitimate projects where we said, “Wait. We need to be thinking about this first.” It was made for a phone, or it was made for a tablet of some kind. When you start doing that, I think it becomes really clear, “Hey, I need to maximize this device and what it can do, but I want to have my program as its base to be available to give that everything it needs at the right time.”
Michael Smith: What about folks who have ORM code? Maybe they're using Hibernate built into ColdFusion to abstract their data layout. Is that something you'd move to REST as well?
Nathaniel F.: Yes, I would. Our key clients that we work with, they have very solid ORM Hibernate setups for their back ends. That was probably my key experience has been working with ORM as being with a REST interface. Yes, that's a perk sweet spot for it. You're talking about two things that ColdBox excels at.
ColdBox excels at ORM tooling and management. If you put a REST API on top of that, you're just simplifying and enabling a presentation.
Michael Smith: You mentioned before we started the interview that you've got a project where you've got Couchbase behind REST. For people who don't know what Couchbase is, that's some kind of distributed database that's not quite SEQL? Is that a fair summary?
Nathaniel F.: That's a good summary. Yes, that's absolutely a good summary. Data modeling has changed in the last few years to use not just SEQL, which most developers are quite comfortable with. It is a solid solution.
There's also been an emerging, especially with highly scalable web development, with this idea of NoSQL, which some of us have relabeled more document database type thing. Really, what it tends to be is large packets of JSON data as documents that you use instead of tables that you used to use in SEQL. That's not an exact comparison, or a description, because there's a few other ideas you need to work around.
Couchbase was the one that I chose to work with for two reasons. One, the ColdBox community has already had some work in it. We have a Couchbase model that I'm using in this application. The Lucy community has also has an extension specifically for Couchbase. Brad Wood, who anybody in the ColdBox world knows well, really likes the abilities and the specifics of Couchbase. He's been using it.
In the last year, I got to work on a pretty high profile project for our company that used Couchbase as its data source. Since I had that experience, I though if I'm going to bring something to a convention and show it off, I would like to show off this as an option. People can ask questions. They can see it. I can tell them what I believe works and how it works. They could also see how smooth it can be as an option for a back end.
I still believe that a lot of traditional developers will use ORM and use SEQL. Those are solid and tried and true methods. This will give them an opportunity to see something different, something that's a little bit lighter. As an application, it's a little leaner. It doesn't need those Hibernate elements to it. It interacts with the data in a slightly different way.
Michael Smith: What would be an advantage of using a NoSQL database like Couchbase over MySQL, or SQL Server?
Nathaniel F.: We've debated that a number of times recently with our newer projects. It usually boils down to a data strategy and scalability. There are certain data strategies that lend very well to a NoSQL relationship. That would be if you're using a few different types of data that could be documents and there's going to be a lot of them.
That would only really turn into five, or six tables in a SEQL database, which really doesn't even feel right. For a NoSQL solution, that's actually very elegant and simple.
The other one is scalability. SEQL is amazing and highly performant, but these NoSQL databases were made for systems that were going to expand to, I would just say ridiculous numbers of people at complete … Using them all at the same time, high intensity. They were designed for that.
That's built into the project, I would definitely consider it. That really be the sweet spot, something that has a simple and straight forward data structure that's not as wide, and vast, and complex as we're used to with SEQL, but also has that intensity and scalability built into it.
The project that we worked on in the last year fit those criteria to a T. The data structure was simple, but the use case was going to be very intensive. We were pretty happy with Couchbase as our solution for that.
Michael Smith: Cool. Let me switch gears a moment here. I'll ask you a different question. Why are you proud to develop in ColdFusion?
Nathaniel F.: I'm proud to develop in ColdFusion, because it has the combination. Specifically, being a part of the ColdBox and a lot of the open source community as part of ColdFusion, because we have two things.
One, we have a great tradition. We have been a part of some of the greatest highs and a few of the lows of the web development history. Also, we've got some tenacity in there. A lot of the people who are very strong in the CFML community are people who have been doing this for a while and they've been doing it well. That's tenacity to not go from one thing, to the next thing, to the next thing, but really craft something solidly and well.
Third, we've got some of the most forward thinking, and highly developed, and amazing tools that we could imagine. We're going to be hanging out and into the box with the guy that invented CommandBox, as well as the guy that invented ColdBox itself. These are some just amazing tools that the CFML community has been blessed with.
I think we have the key parts that I would want in any community, tradition. We've got time honored tenacity and we've got some innovation, and forward thinking. That's exactly what I want to be a part of.
Michael Smith: Cool. I know sometimes people think ColdFusion's not doing so well. My view is and why I started this podcast, ColdFusion Alive, is because I'd like ColdFusion to be more alive, and more active, and have a community that's cheering it on and making cool things happen. What do you think it would take to make ColdFusion more alive this year?
Nathaniel F.: I think perspective helps some people. I know some people I've talked with, they think ColdFusion is old. There's a lot of things that are old. Being old doesn't necessarily mean you're not good. In fact, being old means that you've been tried and true in some ways. The question is whether you're moving forward.
That's where, again, this part of this community is very much moving forward. That's what helps bring it alive. I would know if we talked about certain things, helping to participate, and making tools, and making things like modules, and assisting with these frameworks and stuff, and introducing people to things that are just a new and fresh way of doing what they've already done, that's making it live.
Being willing to make the best of a tool that you know, rather than looking for the next silver bullet, because you go to any social media resource for developers, we're always looking for the next hot thing and the next silver bullet. It just rolls into the next, and it rolls into the next one. After a while, you're like, “Do I have something in my tool shed that I really look at and say, I can turn.”
For us, the language and many of these ColdBox related tools have done that for us. When we make a new project, we feel like we have something that could be both innovative and tried and true. To us, that's a no brainer. It's like why would you not reach for something that's tried and true and innovative and you can make a great product with?
Michael Smith: Makes sense to me. What are you looking forward to at the Into the Box conference?
Nathaniel F.: I love people. I love you guys. Every time we have a chance to get together, I just soak in the experience of being able to be a part of you guys. I'm, of course, going to learn some really neat stuff. There are some really, really cool presentations that are going to take place.
I want to learn more. More than anything, I want to be able to rub shoulders with you guys again and hear how you guys are doing, and what you've been doing, and learning a bit of what you guys have learned in the last year or so, since we've last seen each other.
Michael Smith: Cool. I saw in your bio, you're a sci-fi enthusiast. If I had to make you pick one sci-fi novel, what's your favorite and why?
Nathaniel F.: I was talking about this yesterday with Seth, ironically, one of our other CTX guys who is also speaking at Into the Box. I was tossing around two of my favorite classics. One of them is Ender's Game by Orson Scott Card, which they made a mediocre movie about. The other one is Dune by Frank Herbert, which they made some horrible movies about. Both of those book capture my imagination. I've read them each four, or five times. I don't …
Michael Smith: Maybe we should combine them together. Do a get merge on Ender's Game and Dune.
Nathaniel F.: That would be a really long and interesting novel, but I would give it a whirl.
Michael Smith: There's a lot of sci-fi fans in the ColdFusion community. I thought that was interesting.
Nathaniel F.: The app I'm showing off is ironically going to be Star Wars related. I'm going to take a little bit of science fiction and science fantasy with me.
Michael Smith: Great. If people wanted to find you, Nathan, how would they do that?
Nathaniel F.: I do have a Twitter account, Francainath. I also have a very small web site that I don't blog to very often, francainath.com. Also, you can connect with me on the computer know how's web site that will have a link to me as well.
Michael Smith: Fabulous. Thanks so much for joining us today.
Nathaniel F.: Thank you.