Document Databases vs Relational Databases (Podcast Transcript)
source link: https://hackernoon.com/document-databases-vs-relational-databases-podcast-transcript-kh3g35pr
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Document Databases vs Relational Databases (Podcast Transcript)
@amymtomAmy Tom
Hacker Noon Editor, businesswoman, podcaster, and true crime lover
Javascript developers rejoice! Amy Tom talks to Eric Bishard and Arun Vijayaraghavan about the differences between a Document Database and a Relational Database. Eric and Arun explain JSON Document Databases and also discuss NodeJS SDKs, ODMs vs ORMs, and more. Eric is the Developer Advocate and Arun is a Product Manager; both work at Couchbase.
In this episode, Amy chats to Eric and Arun about:
The differences between a Document Database and a Relational Database (06:56)The differences between an ODM and an ORM (18:45)Learning Nickel Querying through Ottoman ODM (26:58)
Follow Arun Vijayaraghavan and Eric Bishard:
- Follow Arun Vijayaraghavan on GitHub
- Connect with Arun Vijayaraghavan on LinkedIn
- Follow Eric Bishard on Twitter
- Follow Eric Bishard on GitHub
- Follow Eric Bishard on Dev.to
Read more on Hacker Noon:
Eric Bishard's Introduction to Ottoman on Hacker Noon
Shownotes:
Podcast Transcript (Machine Generated - Please Excuse The Errors)
Amy Tom: [00:00:00] it is April. The birds are chirping. The sun is shining. We are here, it's spring and this is the hacker noon podcast. My name is Amy Tom, and today I am joined with Eric and Arun from Couchbase. So Eric, could you please start off by telling us what you do at Couchbase?
Eric: [00:00:30] Sure. So I'm a developer advocate for no JS at Couchbase. I've been working here for just over a year started right before COVID. So that was an interesting way to start a new company. Typically I've been doing developer advocacy for over two years. Worked for a few different companies, landed at Couchbase. Was really kind of, used to traveling and going to conferences and everything, and then started here and kind of all of that, you know, wasn't really possible during COVID.
So it's been an interesting time to be a developer advocate for sure. But yeah, I'm. I joined because we needed to be able to speak to JavaScript and node JS developers and create a better developer experience for them here at Couchbase, which makes a lot of sense. Cause we're at Jason database. And it works really well with JavaScript.
So, yeah, that's right. I am now. And before that I was a software engineer, worked for Tesla and solar city. And then also did a lot of freelance for about 15 years and been programming since about 1999, 2000.
Oh, okay. Wait, what is the main role of a developer advocate?
Yes. So you know, when I first started as developer advocates a lot of the work that I did was about interfacing with the community speaking on behalf of the developers and kind of being a liaison between the developers and the software engineering teams that I worked with.
Things do change a little bit whenever you're not able to get out and interface with the community as much, you know, virtual conferences and meetups are great. They're a harder way to kind of, embed yourself in the community. So with COVID over this last year, the developer advocacy role, I wouldn't say has changed, but we've had to switched things up a little bit, focus a little bit more internally on tools and creating better developer experience. But overall, yeah, I am. I am the person who goes out and interfaces with the community tries to learn as much about what those developers need from whatever company I might be working with in this case couchbase and just trying to make a better seamless developer experience for them, create new tools and and expand the ecosystem and overall just be a voice for them to catch base.
Amy Tom: [00:02:43] That's exciting. Okay. Question for you then. What is your favorite online developer community?
Eric: [00:02:52] Ooh, that's a good one.
I really like Twitter and dev dot Tio. So, Dev dot Tio is a place where developers can go and post articles about pretty much anything developer related. Twitter's an interesting place. I w I, I would say it's a love, hate relationship with Twitter. You know, it's, it's a great place for us to get out there and, you know, gain followers and, and, and tell people about what we're doing.
Obviously it can open up other opportunities for feedback and stuff like that, which is always really interesting. But again, that's a great developer platform. You know, I've published articles or re recently published an article on hacker noon. So I'm starting to get into that community and let's see another, like I have a lot of them, so probably even you know, back in the day, it used to be a lot of people would get on stack overflow.
But Right, right. It's great. It's an interesting place to go and be part of the community, but I would say that's up there at the top of my list, but. Dev dot Tio is really one of my favorites. It really gives anyone the ability to publish articles. And I'm finding kind of the same kind of thing with hacker noon as well.
You know, get out there your content, let people comment on it, give feedback. And these are really great for developers and also developer advocates.
Amy Tom: [00:04:08] Perfect. Excellent. Thank you very much. Aroon could you please share with me what you do at Couchbase?
Arun: [00:04:15] Absolutely. And thank you, Amy. I'm I'm a product manager.
I take care of nine different SDKs and four-plus connectors. It's still adding to my list. So I'm, I'm predominantly responsible for making strategic decisions and taking the products to the next level, you know, doing market research analysis you know, talking to different developers, talking to You know, people like Eric, who is from a developer advocacy background, we'll see what are the pain points?
What could add more value, take the product to the next level talking to customers and different stakeholders, you know, stakeholders and unlimited this this kind of job. So prior to that, and the reason it comes in handy To be a product manager is because of my background. What I've been doing in the past is I was I started my career in 1990s.
As, as a developer grew up, the architect was a manager and we need two different roles, different shoes. And this product manager role is something that I took up alongside when Eric joined about a year ago. And that this role basically gave me a lot of opportunities to look from the other side, you know, I've been a consumer of product, and now I'm kind of a person who is building products, I'm giving products a new direction.
Right. So, so now that, that kind of covers me from a three 60 degree when it comes to my profession. So it's really exciting to know. Like what, what would it take for the developers and other community to benefit out of a product? Right. So that's, that's pretty much it.
Amy Tom: [00:05:48] Sorry. Did you say how long you've been working there
Arun: [00:05:53] at about a year now for about 20 years?
Amy Tom: [00:05:59] Where are some other places that you work? Where do you just start?
Arun: [00:06:05] So I, I, my, my career goes back You know, I've worked for smaller companies worked for energy background energy back from based companies worked for a telecom industry, financial domain, right?
So I started back in 1999 for a very small startup company. We used to do VB basic COBOL, you know, all the low level programming languages, it's surprising that I call them low level allow because technology has advanced so much. But have seen technology growing to a massive extent. And so. The collective experiences that I have along with what I'm doing today really is helping me shape up the product.
Amy Tom: [00:06:46] Awesome. Okay. So I want to get into some database stuff. Eric, could you give a brief overview of what Couchbase actually
Eric: [00:06:55] is
sure. So Couchbase is a document database. If you've worked with relational databases in the past, like Microsoft SQL server or my SQL, those are relational databases. And in order to insert data into them, they are very rigid. You have to define all of your tables, columns, and fields with certain data types.
And when you insert into them you have to jump through some hoops. Let's just say with Couchbase it is a document database, so we don't store data as. Tables and columns. We store them as Jace on documents and for JavaScript developers, that's a big plus because they can work with Jason and JavaScript objects, basically full stack.
And that is It's great for JavaScript developers because we're already working with those types of objects in our applications. And when we get the data back from the database in a familiar format, there's not a lot of transformation that needs to happen. It's pretty seamless as well. You can just Chuck information into that database as, as quickly as you, as you need to.
Sometimes they call these transactional databases and. If you think maybe for a company that does user profile like stores, user profiles, like LinkedIn, LinkedIn is a big customer of ours. And so if you have a LinkedIn account, your information is stored somewhere in a Couchbase database and it's just a big Jason object.
But what sets Couchbase apart? From some of the others is that we use nickel. It is a, query language that's based off of SQL. So if you're coming from a relational background, a lot of the concepts that you already know around querying data when you start with Couchbase, you pretty much know 90% of how to work with our query language
However, there are some differences in fact that you can nest documents inside of a Couchbase. Server and you kind of can't do that with a relational database. So there, there are some little bit of differences in the way that you would structure your queries based off of that. But other than that if you know how to do a basic select star from whatever table and, you know, based off of this ID, that same kind of logic carries over to Couchbase and it makes it really easy to transition from relational database over to Couchbase. And one thing I would say there's a lot of people say You know, in a document database if you bring all of these concepts from relational database over that span. And, and I don't really agree with that. I think that the only thing that's interesting about nickel as a query language is that you're able to kind of bring some of the knowledge that you already have from querying over, but that doesn't dictate kind of how you work with the database or how you store data.
There is a new kind of mindset that you have to get into when, when storing data. So. Hopefully that clears it up a little bit, but yeah, we're at Jason we're at Jason data store.
Amy Tom: [00:09:55] Okay. Uh, Rune, I would love to hear some more about the differences between relational database and document database, but in a use case kind of scenario.
Arun: [00:10:08] So I give you an example. I come from an energy background, right? So, we actually, the, a very good use case would be the one which I personally went through and I would like to share that. So. One of the scenarios in an energy background is that you store customer information, you store customer payment information, you store customer billing information. Right. And we initially started off using structured RDBMS kind of secret database. Right? So database is grew up really fast because we had to define everything within different tables.
And we had to maintained a lot of relationships and that quickly became a bottleneck. Why? Because as, and when the customer base grows as in when the market expands you tend to. A similar snapshot of tables across the board, say even to Japan in our previous company, right?
So we had to create a similar set of tables, the relationships for customers in Japan, because they had different governance, they had different you know, policies around right now. Eventually that was becoming a bottleneck and we were given this you already say a golden key.
We were saying. Go ahead and change everything, whatever you want. And the best opportunity that we got was to change the database as well. And the decision we took was to move from a relational kind of database to document data. Right? So, The benefit you get out of Eric Wright leaks clean it's the first-class citizen is a Jason document.
And then you don't have this for head of media relations. You have objects, you haven't messed it up. So you have, you can have customer, you can have customers products, you can have customers orders, order details, products, everything. As, you can define within a single document. So you don't have this overhead of meaning different relations
And then one of the other use case is, Hey And reading invoices and producing invoices, right?
So, an invoice is essentially. What it's, it's a document. Right. If you were not think about having something like a document database, which we didn't have in the past, maybe 10, 15 years ago, but we never talked about the document data, right? Everything was stored in a structured way.
You got like in, in tables and to scoop up all of this data is basically a big performance hit. Okay. And then you also have this problem, managing and maintaining all of these different data and different relationship tables. If you now fast forward and come to you know, maybe five, six years or maybe 10 years later in early 2010s, right?
When based database started growing and showing up its presence. I think it's also a big deep in In actually you know, helping with these use cases like generating invoices you know, you, you call it an invoice. It's a document. Why not just store it in a document structure.
So it makes more sense. So, what databases trying to do is. It's trying to make more sense, I'm not saying that you. You have to strictly be documented, right? You can have a hybrid, you can have relational, you can have documentaries, right?
Amy Tom: [00:13:17] Right. When do you say that a document database is harder to query as opposed to a relational one?
Arun: [00:13:25] Very good question. Right? So the answer is, depending on which document database you're talking about, if you talk about Couchbase like Eddie gripey mentioned, we have a very powerful nickel committee which sits on top of you know, Couchbase, which helps you basically query your cheese on that.
Right. So it depends on what choice you make. Again the question about, am I choosing the right database? Stands out because it has not of other powerful tools, one being equal. it's still lingers. It's still there. And coach There are, there are others like search features.
Like the search feature is super powerful. You can basically get what you get from say, elastic search if you work from cultures. So it's one shop, you buy cultures, you get everything. So why not? Couchbase so answering to your question. Yes, you can think of it. Hey is definitely hard.
I'm coming from a simple word. I have rehab only learned relationships. Right? I know relations. I don't know that. How long? Oh my God. It's going to be a a very painful task. If you pay, if you choose Couchbase, all of your problems are solved in one.
Eric: [00:14:31] I can add something to that real quick. So two things, one I'll start with the querying.
So. When I first started learning about relational databases I learned about SQL and it was the one of the easiest languages. If you want to call it a language, it's a query language that I I'd ever learned before. And it just made sense. It was plain English, right? Select. You know, this field, this field in this field, from this table where the ID is, you know, my personal ID or this hotel ID or something.
Right. So, that's very easy to remember in your head and understand how to Create that query. When you come over to Couchbase, you don't have to forget that you take, you bring all of that knowledge with you of how to use a SQL and you can apply it directly to Couchbase. So that's, that's one thing.
I was going to say it, you know, kind of already talked about that, but another thing too, is that rune was hitting on. Is, you know, what, if your database is a travel database and it keeps track of hotels in the United States and, and for a hotel in the United States, let's say that you have four fields that you're tracking, right.
We're gonna keep it simple. And then you expand into the EU, right. Or, or Asia or something like that. And all of a sudden there are new fields that you have to track for this new country. Who knows why. Maybe their phone numbers are different. Again, I don't know why, but all of a sudden you have to track a few more fields in a relational database.
There's a few different ways of doing this, but the most simplest way is that you just add the extra fields that you need for Europe into that main. Hotel table or whatever it is. And now when you're storing documents for the United States, you have these extra fields that are just know, or don't have any information.
And that these fields were created for this new territory that you're in. And now there's, there's ways to kind of normalize that and kind of separate that out and say, you know, here are the extra things I need to know for each different country and a document database. You can just structure the United States hotels one way.
And the European ones a different way, and just literally just Chuck them into the database. There is no schema upon writing to the database. You don't have to conform to a certain shape in order to stick it into the database. However, when you read that information from the database, Using something like nickel our query language, you can reshape the information you're pulling out and give it to your API in a certain shape for United States and a certain shape for you know, Europe or, or whatever.
So that's very powerful. And that's what kind of what he's talking about. It's a flexible schema and an option which we didn't have in the past when you use it. Relational databases.
Amy Tom: [00:17:17] Okay. Yeah. I would love to talk about how I I've seen online that Couchbase Ottoman has been often compared to mongoose DB. And I would love to talk about that, but first I feel like we need to take a step back and maybe talk about what an DM actually is.
Eric: [00:17:33] Yeah, I can start there. I'll make one correction real quick. So, Mongo is kind of, I wouldn't even really call them a competitor that they are another document database out there. Mongoose is analogous to Ottoman. So Ottoman is an ODM for Couchbase and mongoose is an ODM for Mongo.
And now, yeah, so. Sorry. And then the question again was what is it? Yep. So, an object ODM is an object data mapper, and in relational databases you have something called an ORM, an object, relational map mapper. So if you're a C-sharp developer, you might think of in hibernate or entity framework, or maybe an a micro RM like dapper, these are the ORMs for those This is specifically for C-sharp developers working with Microsoft SQL server.
Right? So these tools enable binding between your application objects, which are either pocos that's plain old C-sharp objects, or plain old Java objects. I'm just using C-sharp and Java. But so this provides a relational representation of the data in your relational database. And there is transformation that needs to happen kind of from your database to your application.
And ODM is an object document mapper. So it's very similar to an ORM. The name suggests it maps a document to an application object basically enabling the, a way to define the structure of a document in the form of schemes and models. So even though we are a schema flexible and Couchbase, it doesn't really matter how you put the information into the database, what the document looks like.
Your application still has requirements and still has a schema requirements. So what this ODM allows you to do is define the, those, the shapes of your documents and so that you can. Basically persist data from your application into the database. And it also allows us ODM also allows for validation.
Validation is probably one of the biggest ones. So when you're putting information into a Couchbase database, we don't have a lot of requirements or ability to check a validation very easily, but with the ODM, that's kind of a layer in front of the database. And in front of the SDK, even that allows you to kind of define these shapes of your documents.
You know, for instance this certain field needs to be a number of this certain field needs to be a string that certain fields needs to be a phone number, right. When you're, when you're just in inserting information to a Couchbase database or any document database, it doesn't care what those types are for each field, but with an ODM, it allows you to define those things.
Amy Tom: [00:20:07] Okay. So when you say shape of your document, that means that you, it, it has certain fields.
Eric: [00:20:16] So for our hotel, I need a hotel name. I need the phone number, potentially an address, maybe a multitude of addresses. And each of those fields, even though the, the database doesn't really care how you put them in the application says, Hey if I go to try and read this document in the future, and this certain field is not a number or this certain field is not a shrink, we're going to have issues.
So the ODM kind of allows you to, to define that shape and those, this validation,
Amy Tom: [00:20:44] and as opposed to a relational mapper, that would be more like line items that the application could refer to that would already be set in there. Right.
Eric: [00:20:55] So it actually works very, so an ORM and an ODM are not really that different.
They just have a different letter in the middle of it to specify whether it's relational or document database oriented. I think with a O an ORM is very important because you have to do a lot of transformation of the data to, and from the database. That transformation doesn't really happen in an ODM, but there's an added feature in the fact that I can now do validation and checking and checking of that schema in the shape of that object, before it gets inserted into the, into the database.
And then with nickel, you can kind of also adhere to a certain shape when you're pulling it out. Go ahead and run.
Arun: [00:21:38] So what I want to add. What you just said, Eric, one other big difference about is that the stickiness, I call it the stickiness. What the stickiness stickiness here is. All of them does lot of other heavy lifting, which can, can impact your performance.
So I come from a, like I said, I was a programmer before I come from a development background. And like Eric rightly said, I was talking about the C sharp Java. That's kind of where it comes from. Right. One of the thing is using an ORM. It tracks your. Database changes. So, so, we are talking about two things, right?
One is a relational database. And on the other hand, the document database, relational database equals and document database equals ODM. That's what we are talking here about. When and, and in relational database, you have tables. You have each tables has. Has that rules and palms columns are average.
It has its own pipe. That's where it defines its constraints and stuff like that. Right. And the ORM BCP mimics your your table structures and its relationships. And it also does a lot of stickiness, like I was describing before. It's kind of like tracking the state of each object, which, which is basically mapping to your table.
So it just basically practicing it. It's also. Doing this check is the relationship. The definition of integrity is a call impact, right? It's doing a lot of, a lot of other things which could have a performance when it comes to audience, it doesn't do all that ODM is basically, it's very lightweight.
It says, okay, I'm going to provide you a list of four set of tools. It's think of it like a Swiss knife, right as this knife, or you want to carry 15 different. Tools large tools in one bag, which one is easy. I would carry a Swiss knife in my pocket. Right. And it has other tools. And ODM is like that.
It has a lot of tools, which you decide what you want to use. Eddie gave you an example. I want to use a validator, for instance, I want to make sure my document, but the documents, which might. You know, my application object is map. I want to make sure that this document is, has the right shape.
It has the right say phone number is in the right format or social security's in the right format. Email is in the right format. Right? I decide, I tell the audience, this is what I need, but I OPM has all of these tools in, in, in a very. Define crafted that a developer you know, a developer who is a novice or a developer who's seasoned you know, they need not learn anything new, all the, you know, what are the different foods?
All I need to do is pick this tool for this job. Right. And then, then just get going. So it's as simple as that. So,
Amy Tom: [00:24:22] yeah, I'm going to put my ODM Swiss pocket knife in my pocket
Eric: [00:24:29] thing I would add is that, you know, when you're building an API and you're just using the SDK or the driver for a database, you have to write all the implementation for how to insert a document, update a document, whatever. And so if I right an endpoint for an API that inserts data, very simple insert, and then a rune writes an end point also for inserting data, we might come up with two different implementations with Ottoman. Two different developers could potentially create an end point where they're inserting data. And they just call one simple command and insert command.
And under the hood, Ottoman is doing them both pretty much the same way.
Amy Tom: [00:25:13] So I want to go back to my previous question then, if mongoose is the Ottoman of Mongo DB, then how does Ottoman stack up?
Eric: [00:25:25] So, Ottoman is a complete rewrite of a previous. It was the same library. It was called Ottoman, but it worked with our SDK too.
And when I came on board that tool had not been updated for a while and it didn't work with our our new SDK. So we decided to rewrite it and I will get to the answer I promise. But we had to rewrite it and we took the opportunity to rewrite this ODM with modern JavaScript and TypeScript.
When we got our first client to try out our ODM Ottoman. We realized immediately that they were actually coming from Mongo and Mongoose over to Couchbase. And so we found out very quickly that there were some features that weren't available to them. Now, we don't ever try to do exactly what Mongoose does Couchbase is a little bit different of a database. There are some differences that need to be there, but we also need to have some parody with it as well. And we're able to use modern documentation features like JS docs and stuff like that.
So, maybe, maybe it will. Maybe one day out of shines longest, I don't know. August is very popular and, and we never want to say that, Hey, this thing's not good. We're better. Or something like that. Uh we're, we're, we're very new, but we, we are, we are trying to create that very basic parody first. And, and then go from there, giving our users the features that they need.
So I would say it stacks up pretty well.
Arun: [00:26:59] One thing I wanted to add and emphasize remember your ID jealous, but gives you back a nickel that we are now reversed. You're learning it the other way. You're learning through. Basically Java's right. So you didn't know Nicole, but you are like I want to find this place which is say China or Japan or whatever, you are basically generating the query, a NEPA query. So, isn't that an exciting way for learning stuff, going and learning explicitly learning a new language you're asking to automation to learn, which you absolutely need that, but you're learning it in a different way,
Eric: [00:27:35] the query builder is fluent API. So you can kind of chain different commands together in order to try and build a query. And then when you're done, it returns the proper nickel string back to you. So you're like, Oh, I chained these few commands together.
Oh, it worked. And by the way, here's string that it generated for me to query my Couchbase database. So you're like you said, you're learning nickel as you're using Ottoman as a tool,
Amy Tom: [00:28:00] Is Nickel something that's popular for developers to learn?
Eric: [00:28:04] It's sequel. So nickel is a cul variant under, underneath the, so if you know, ANSI sequel, a N S I CQL, it's kind of like a standardization of SQL. You can actually use that same ANSI SQL with nickel. So again, when we say nickel, if you're not familiar with it, just think for the most part it's cul you know, 90% that with, with some variations, it is CQL.
And if you know that then you know the majority of nickel,
Arun: [00:28:38] the nickel is more of a sequel on top of Jason. Remember Jason is a semi-structure or may not have any structure. Right. But Jason Brockman, like Eric was saying, I want to add a per region.
I want to add extra fields. You can do that. So you have document Mississippi doesn't have any set defined structure but you can now use nickel on top of Jason to basically slice and dice the GS on document and get the information out of it. So that's a big, big, big process.
A couple of other things, which adding to what you were asking, how, how does it outperforms? How does it outstand? Right. There are quite a few more things. One is it's built on top of our node JS SDK. Okay. And there are a lot of things that are not just as Tiki gives you in terms of performance, in terms of a high availability, like price and stuff, but you need not worry about, so you're issuing a command to the database, which under the hood uses node.
Yes, it does a lot of things like automatic reprice. There are failures network failures. It does automatically, right. You don't even know. So, so that's one of the powerful things which which comes to you free. From, because it's built on top of the other couple of things, which I want to add is one is the future of parliament is amazing. And I think we should talk about it. This is the right time because you asked where we stand, right?
The future is going to be expand Ottoman to not just you know, help developers build rest API. Also bill graph, QL, which Eric will be talking to you maybe after I finished. But that's something which we are we want not just to go on just with automate as an ODM, you want to give it a different, we want to take it to the next level use it to support grad school community.
The other thing, which also stands out. We have something called a field level encryption at client sites, 11 infection. So, you know, how PII the Phi data the you know, the, the governance around data, all there is so much around is my data secure talking about data and the data data is my data secure.
Right? So the future is which we want to introduce. I can just say I have my social security here. Just say encrypt and it's going to encrypt it that's something we want to do going forward. So there are a lot of other things which which are outstanding today, which will eventually make it more and more outstanding as we mature this product.
And Eric said, this is this is getting there, but we have already built out what is the future of argument?
Eric: [00:31:17] What are the next steps for sure.
I was going to say one more thing about nickel because you had asked when you're working with Nicole, you're working with Jason under the hood.
So there are some differences from regular CQL and two of them that come to mind is that one, like you said, we have nested documents and we need a way to be able to we need keywords, like nest. And it added to the language. And we also, in a, in a Jason document, you can store an array, which is basically just a, you know, a bunch of different items in an array.
So normal tables don't have that but to be able to work with an array inside of a SQL statement. So those are some of the things that if you, if you were to go learn nickel yeah. You know, you know, somewhere between 85 and 90%, I'm just pulling that number out of the air.
But there are a few things that you might have to learn Oh, how do I work with Nesta documents? How do I work with arrays? And everything that you need to know about those features are kind of inherent if you're coming from a JavaScript background already, or if you're coming from working with arrays or four loops already, it'll just make sense.
Amy Tom: [00:32:22] Right. Okay. Makes sense. So I would love to end with a question for you guys a little bit. Maybe it's a, even an ice breaker type of question, even though we're doing it at the end, but what do you think that the best programming language in the world
Eric: [00:32:38] is. Do you want me to go first or? Okay. So I was going to say JavaScript, but I think, I think if you're a developer who knows JavaScript already, that TypeScript is actually the thing that if you want to really level up TypeScript is probably the best programming language going so far.
It's created. Bye honors house Berg, who is, I hope I said his name right. Is the creator of C-sharp. And if you know, C-sharp or, you know, JavaScript, or, you know, both TypeScript is like this amazing language that kind of combines the best of typing that you might already know from C-sharp and the best of JavaScript and kind of combined some together, it creates a a super set of the language.
So. An interesting thing with TypeScript is that if you have a JavaScript file and you want to make it TypeScript, you just change the JS to a Ts, right dot, JS to Ts, and it's already a TypeScript file. And now you can start adding those little bits of TypeScript in as you want. So the best programming language right now is TypeScript, I think.
And it sits it kind of expands JavaScript.
Amy Tom: [00:33:52] All right. Bold choice, bold choice around. Do you agree? Do you have a varying opinion?
Arun: [00:33:59] So, I, I do. I do agree, but I want to stay unbiased. I know Eric, you predominant jealous. Yeah. And I, I want to go back to my team. I want to show my face. I do love, I do love all, all of the STKs.
Each programming language has its own sprints. And and you know, limitations, right. That we have to really accept based on the pop blacks. I do understand, and a B that a J JavaScript and TypeScript for that matter is easy to adopt and children document based database. Right. It's very easy. However it doesn't limit other languages.
If you have the right tools, if you have the right methods to do certain tasks. I think each programming language is great on its own gaining in terms of popularity. I totally agree. No JS TypeScript they are getting a lot of popularity, but you know, that doesn't necessarily mean that other programming languages are not it's, it's, it's you know, it's a give or take, you know, this is
Amy Tom: [00:35:02] a very diplomatic answer.
I don't know. I'm not going to let you get away with that. I want to know what you think is the best programming language in the world.
Arun: [00:35:23] I would agree with that.
Eric: [00:35:27] And let me add something to that. So, so if you come to Couchbase right, and you want to get. Acclimated with, with Ottoman. My suggestion is to try out our no JS SDK it's JavaScript. It is, I believe that one of the easiest ways to get started with Couchbase because there's less barriers and, and less of an on-ramp to learn Couchbase through some.
Programming language, which is transforming your, you know, your Jason objects into different classes and stuff with JavaScript, you can just work with JavaScript objects from the client all the way to the server. So if someone wanted to get started with Couchbase, I would say, Hey, come check out our node JS SDK, get started there.
Once you build a simple demo maybe a, a simple demo API, then kind of move over to Ottoman and and check that out. And and I believe that you will have the lowest amount of friction. If you go the JavaScript route again, I'm very biased, but that's, you know, I wanted to kind of change that answer.
Not only my favorite programming language, but also like it, Hey, if you want to come check out Couchbase, which we would love for you to do. Love for you to check out Couchbase R no JSS DK or any of our SDKs, but obviously also Ottoman, you know, check out. We're going to have resources and links along with the podcast.
So check those out and always reach out to me or a rune. Our DMS are always open and we can help you get started.
Amy Tom: [00:36:47] Cool. So if they do want to start testing and contributing to Ottoman, where can they look?
Eric: [00:36:53] So get hub. Has a repository or a repository called node dash Ottoman. So they can go there to, to check out how Ottoman is built.
And beyond that, if you want to get started with documentation right now, it's V2, Ottoman. Js.com. Okay. I
Amy Tom: [00:37:14] will put some of these links in the show notes and Eric, where can our listeners find you
Eric: [00:37:20] Twitter? Is the best however Twitter . Get hub and dev dot Tio. My username is HTTP junkie, J U N K I E,
Amy Tom: [00:37:31] and a ran.
Where can we find you?
Arun: [00:37:32] You can reach out to me by our get hub or LinkedIn. My handle is AB in five, two, four.
Eric: [00:37:43] Yeah.
Create your free account to unlock your custom reading experience.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK