mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-28 01:01:09 +08:00
remove ryanmccue.ca
This commit is contained in:
darksun
parent
3d0be8766c
commit
f222d6cc8f
@ -1,56 +0,0 @@
|
||||
Your API is missing Swagger
|
||||
======
|
||||
|
||||
|
||||
|
||||
We have all struggled through thrown together, convoluted API documentation. It is frustrating, and in the worst case, can lead to bad requests. The process of understanding an API is something most developers go through on a regular basis, so it is any wonder that the majority of APIs have horrific documentation.
|
||||
|
||||
[Swagger][1] is the solution to this problem. Swagger came out in 2011 and is an open source software framework which has many tools that help developers design, build, document, and consume RESTful APIs. Designing an API using Swagger, or documenting it after with Swagger helps everyone consumers of your API seamlessly. One of the amazing features which many people do not know about Swagger is that you can actually **generate** a client from it! That's right, if a service you're consuming has Swagger documentation you can generate a client to consume it!
|
||||
|
||||
All major languages support Swagger and connect it to your API. Depending on the language you're writing your API in you can have the Swagger documentation generated from the actual code. Here are some of the standout Swagger libraries I've seen recently.
|
||||
|
||||
### Golang
|
||||
|
||||
Golang has a couple great tools for integrating Swagger into your API. The first is [go-swagger][2], which is a tool that lets you generate the scaffolding for an API from a Swagger file. This is a fundamentally different way of thinking about APIs. Instead of building the endpoints and thinking about new ones on the fly, go-swagger gets you to think through your API before you write a single line of code. This can help visualize what you want the API to do first. Another tool which Golang has is called [Goa][3]. A quote from their website sums up what Goa is:
|
||||
|
||||
> goa provides a novel approach for developing microservices that saves time when working on independent services and helps with keeping the overall system consistent. goa uses code generation to handle both the boilerplate and ancillary artifacts such as documentation, client modules, and client tools.
|
||||
|
||||
They take designing the API before implementing it to a new level. Goa has a DSL to help you programmatically describe your entire API, from endpoints to payloads, to responses. From this DSL Goa generates a Swagger file for anyone that consumes your API, and it will enforce your endpoints output the correct data, which will keep your API and documentation in sync. This is counter-intuitive when you start, but after actually implementing an API with Goa, you will not know how you ever did it before.
|
||||
|
||||
### Python
|
||||
|
||||
[Flask][4] has a great extension for building an API with Swagger called [Flask-RESTPlus][5].
|
||||
|
||||
> If you are familiar with Flask, Flask-RESTPlus should be easy to pick up. It provides a coherent collection of decorators and tools to describe your API and expose its documentation properly using Swagger.
|
||||
|
||||
It uses python decorators to generate swagger documentation and can be used to enforce endpoint output similar to Goa. It can be very powerful and makes generating swagger from an API stupid easy.
|
||||
|
||||
### NodeJS
|
||||
|
||||
Finally, NodeJS has a powerful tool for working with Swagger called [swagger-js-codegen][6]. It can generate both servers and clients from a swagger file.
|
||||
|
||||
> This package generates a nodejs, reactjs or angularjs class from a swagger specification file. The code is generated using mustache templates and is quality checked by jshint and beautified by js-beautify.
|
||||
|
||||
It is not quite as easy to use as Goa and Flask-RESTPlus, but if Node is your thing, this will do the job. It shines when it comes to generating frontend code to interface with your API, which is perfect if you're developing a web app to go along with the API.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Swagger is a simple yet powerful representation of your RESTful API. When used properly it can help flush out your API design and make it easier to consume. Harnessing its full power can save you time by forming and visualizing your API before you write a line of code, then generate the boilerplate surrounding the core logic. And with tools like [Goa][3], [Flask-RESTPlus][5], and [swagger-js-codegen][6] which will make the whole experience of architecting and implementing an API painless, there is no excuse not to have Swagger.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://ryanmccue.ca/your-api-is-missing-swagger/
|
||||
|
||||
作者：[Ryan McCue][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://ryanmccue.ca/author/ryan/
|
||||
[1]:http://swagger.io
|
||||
[2]:https://github.com/go-swagger/go-swagger
|
||||
[3]:https://goa.design/
|
||||
[4]:http://flask.pocoo.org/
|
||||
[5]:https://github.com/noirbizarre/flask-restplus
|
||||
[6]:https://github.com/wcandillon/swagger-js-codegen
|
||||
@ -1,54 +0,0 @@
|
||||
5 Podcasts Every Dev Should Listen to
|
||||
======
|
||||
|
||||
|
||||
|
||||
Being a developer is a tough job, the landscape is constantly changing, and new frameworks and best practices come out every month. Having a great go-to list of podcasts keeping you up to date on the industry can make a huge difference. I've done some of the hard work and created a list of the top 5 podcasts I personally listen too.
|
||||
|
||||
### This Developer's Life
|
||||
|
||||
Unlike many developer-focused podcasts, there is no talk of code or explanations of software architecture in [This Developer's Life][1]. There are just relatable stories from other developers. This Developer's Life dives into the issues developers face in their daily lives, from a developers point of view. [Rob Conery][2] and [Scott Hanselman][3] host the show and it focuses on all aspects of a developers life. For example, what it feels like to get fired. To hit a home run. To be competitive. It is a very well made podcast and isn't just for developers, but it can also be enjoyed by those that love and live with them.
|
||||
|
||||
### Developer Tea
|
||||
|
||||
Don’t have a lot of time? [Developer Tea][4] is "A podcast for developers designed to fit inside your tea break." The podcast exists to help driven developers connect with their purpose and excel at their work so that they can make an impact. Hosted by [Jonathan Cutrell][5], the director of technology at Whiteboard, Developer Tea breaks down the news and gives useful insights into all aspects of a developers life in and out of work. Cutrell explains listener questions mixed in with news, interviews, and career advice during his show, which releases multiple episodes every week.
|
||||
|
||||
### Software Engineering Today
|
||||
|
||||
[Software Engineering Daily][6] is a daily podcast which focuses on heavily technical topics like software development and system architecture. It covering a range of topics from load balancing at scale and serverless event-driven architecture to augmented reality. Hosted by [Jeff Meyerson][7], this podcast is great for developers who have a passion for learning about complicated software topics to expand their knowledge base.
|
||||
|
||||
### Talking Code
|
||||
|
||||
The [Talking Code][8] podcast is from 2015, and contains 24 episodes which have "short expert interviews that help you decode what developers are saying." The hosts, [Josh Smith][9] and [Venkat Dinavahi][10], talk about diverse web development topics like how to become an effective junior developer and how to go from junior to senior developer, to topics like building modern web applications and making the most out of your analytics. This podcast is perfect for those getting into web development and those who look to level up their web development skills.
|
||||
|
||||
### The Laracasts Snippet
|
||||
|
||||
[The Laracasts Snippet][11] is a bite-size podcast where each episode offers a single thought on some aspect of web development. The host, [Jeffrey Way][12], is a prominent character in the Laravel community and runs the site [Laracasts][12]. His insights are broad and are useful for developers of all backgrounds.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Podcasts are on the rise and more and more developers are listening to them. With such a rapidly expanding list of new podcasts coming out it can be tough to pick the top 5, but if you listen to these podcasts, you will have a competitive edge as a developer.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://ryanmccue.ca/podcasts-every-developer-should-listen-too/
|
||||
|
||||
作者：[Ryan McCue][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://ryanmccue.ca/author/ryan/
|
||||
[1]:http://thisdeveloperslife.com/
|
||||
[2]:https://rob.conery.io/
|
||||
[3]:https://www.hanselman.com/
|
||||
[4]:https://developertea.com/
|
||||
[5]:http://jonathancutrell.com/
|
||||
[6]:https://softwareengineeringdaily.com/
|
||||
[7]:http://jeffmeyerson.com/
|
||||
[8]:http://talkingcode.com/
|
||||
[9]:https://twitter.com/joshsmith
|
||||
[10]:https://twitter.com/venkatdinavahi
|
||||
[11]:https://laracasts.simplecast.fm/
|
||||
[12]:https://laracasts.com
|
||||
@ -1,48 +0,0 @@
|
||||
Blueprint for Simple Scalable Microservices
|
||||
======
|
||||
|
||||
|
||||
|
||||
When you're building a microservice, what do you value? A fully managed and scalable system? It's hard to know where to start with AWS; there are so many options for hosting code, you can use EC2, ECS, Elastic Beanstalk, Lambda. Everyone has patterns for deploying microservices. Using the pattern below will provide a great structure for a scalable microservice architecture.
|
||||
|
||||
### Elastic Beanstalk
|
||||
|
||||
The first and most important piece is [Elastic Beanstalk][1]. It is a great, simple way to deploy auto-scaling microservices. All you need to do is upload your code to Elastic Beanstalk via their command line tool or management console. Once it's in Elastic Beanstalk the deployment, capacity provisioning, load balancing, auto-scaling is handled by AWS.
|
||||
|
||||
### S3
|
||||
|
||||
Another important service is [S3][2]; it is an object storage built to store and retrieve data. S3 has lots of uses, from storing images, to backups. Particular use cases are storing sensitive files such as private keys, environment variable files which will be accessed and used by multiple instances or services. Finally, using S3 for less sensitive, publically accessible files like configuration files, Dockerfiles, and images.
|
||||
|
||||
### Kinesis
|
||||
|
||||
[Kinesis][3] is a tool which allows for microservices to communicate with each other and other projects like Lambda, which we will discuss farther down. Kinesis does this by real-time, persistent data streaming, which enables microservices to emit events. Data can be persisted for up to 7 days for persistent and batch processing.
|
||||
|
||||
### RDS
|
||||
|
||||
[Amazon RDS][4] is a great, fully managed relational database hosted by AWS. Using RDS over your own database server is beneficial because AWS manages everything. It makes it easy to set up, operate, and scale a relational databases.
|
||||
|
||||
### Lambda
|
||||
|
||||
Finally, [AWS Lambda][5] lets you run code without provisioning or managing servers. Lambda has many uses; you can even create the whole APIs with it. Some great uses for it in a microservice architecture are cron jobs and image manipulation. Crons can be scheduled with [CloudWatch][6].
|
||||
|
||||
### Conclusion
|
||||
|
||||
These AWS products you can create fully scalable, stateless microservices that can communicate with each other. Using Elastic Beanstalk to run microservices, S3 to store files, Kinesis to emit events and Lambdas to subscribe to them and run other tasks. Finally, RDS for easily managing and scaling relational databases.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://ryanmccue.ca/blueprint-for-simple-scalable-microservices/
|
||||
|
||||
作者：[Ryan McCue][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://ryanmccue.ca/author/ryan/
|
||||
[1]:https://aws.amazon.com/elasticbeanstalk/?nc2=h_m1
|
||||
[2]:https://aws.amazon.com/s3/?nc2=h_m1
|
||||
[3]:https://aws.amazon.com/kinesis/?nc2=h_m1
|
||||
[4]:https://aws.amazon.com/rds/?nc2=h_m1
|
||||
[5]:https://aws.amazon.com/lambda/?nc2=h_m1
|
||||
[6]:https://aws.amazon.com/cloudwatch/?nc2=h_m1
|
||||
@ -1,60 +0,0 @@
|
||||
5 Things to Look for When You Contract Out the Backend of Your App
|
||||
======
|
||||
|
||||
|
||||
|
||||
For many app developers, it can be hard to know what to do when it comes to the backend of your app. There are a few options, Firebase, throw together a quick Node API, contract it out. I am going to make a blog post soon weighing the pros and cons of each of these options, but for now, let's assume you want the API done professionally.
|
||||
|
||||
You are going to want to look for specific things before you give the contract to some freelancer or agency.
|
||||
|
||||
### 1. Documentation
|
||||
|
||||
Documentation is one of the most important pieces here, the API could be amazing, but if it is impossible to understand which endpoints are available, what parameters they provide, and what they respond with you won't have much luck integrating the API into your app. Surprisingly this is one of the pieces with most contractors get wrong.
|
||||
|
||||
So what are you looking for? First, make sure they understand the importance of documentation, this alone makes a huge difference. Second, the should preferably be using an open standard like [Swagger][1] for documentation. If they do both of these things, you should have documentation covered.
|
||||
|
||||
### 2. Communication
|
||||
|
||||
You know the saying "communication is key," well that applies to API development. This is harder to gauge, but sometimes a developer will get the contract, and then disappear. This doesn't mean they aren't working on it, but it means there isn't a good feedback loop to sort out problems before they get too large.
|
||||
|
||||
A good way to get around this is to have a weekly, or however often you want, meeting to go over progress and make sure the API is shaping up the way you want. Even if the meeting is just going over the endpoints and confirming they are returning the data you need.
|
||||
|
||||
### 3. Error Handling
|
||||
|
||||
Error handling is crucial, this basically means if there is an error on the backend, whether it's an invalid request or an unexpected internal server error, it will be handled properly and a useful response is given to the client. It's important that they are handled gracefully. Often this can get overlooked in the API development process.
|
||||
|
||||
This is a tricky thing to look out for, but by letting them know you expect useful error messages and maybe put it into the contract, you should get the error messages you need. This may seem like a small thing but being able to present the user of your app with the actual thing they've done wrong, like "Passwords must be between 6-64 characters" improves the UX immensely.
|
||||
|
||||
### 4. Database
|
||||
|
||||
This section may be a bit controversial, but I think that 90% of apps really just need a SQL database. I know NoSQL is sexy, but you get so many extra benefits from using SQL I feel that's what you should use for the backend of your app. Of course, there are cases where NoSQL is the better option, but broadly speaking you should probably just use a SQL database.
|
||||
|
||||
SQL adds so much added flexibility by being able to add, modify, and remove columns. The option to aggregate data with a simple query is also immensely useful. And finally, the ability to do transactions and be sure all your data is valid will help you sleep better at night.
|
||||
|
||||
The reason I say all the above is because I would recommend looking for someone who is willing to build your API with a SQL database.
|
||||
|
||||
### 5. Infrastructure
|
||||
|
||||
The last major thing to look for when contracting out your backend is infrastructure. This is essential because you want your app to scale. If you get 10,000 users join your app in one day for some reason, you want your backend to handle that. Using services like [AWS Elastic Beanstalk][2] or [Heroku][3] you can create APIs which will scale up automatically with load. That means if your app takes off overnight your API will scale with the load and not buckle under it.
|
||||
|
||||
Making sure your contractor is building it with scalability in mind is key. I wrote a [post on scalable APIs][4] if you're interested in learning more about a good AWS stack.
|
||||
|
||||
### Conclusion
|
||||
|
||||
It is important to get a quality backend when you contract it out. You're paying for a professional to design and build the backend of your app, so if they're lacking in any of the above points it will reduce the chance of success for but the backend, but for your app. If you make a checklist with these points and go over them with contractors, you should be able to weed out the under-qualified applicants and focus your attention on the contractors that know what they're doing.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://ryanmccue.ca/things-to-look-for-when-you-contract-out-the-backend-your-app/
|
||||
|
||||
作者：[Ryan McCue][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://ryanmccue.ca/author/ryan/
|
||||
[1]:https://swagger.io/
|
||||
[2]:https://aws.amazon.com/elasticbeanstalk/
|
||||
[3]:https://www.heroku.com/
|
||||
[4]:https://ryanmccue.ca/blueprint-for-simple-scalable-microservices/
|
||||
@ -1,88 +0,0 @@
|
||||
Where to Get Your App Backend Built
|
||||
======
|
||||
|
||||
|
||||
|
||||
Building a great app takes lots of work. From designing the views to adding the right transitions and images. One thing which is often overlooked is the backend, connecting your app to the outside world. A backend which is not up to the same quality as your app can wreck even the most perfect user interface. That is why choosing the right option for your backend budget and needs is essential.
|
||||
|
||||
There are three main choices you have when you're getting it built. First, you have agencies, they are a company with salespeople, project managers, and developers. Second, you have market rate freelancers, they are developers who charge market rate for their work and are often in North America or western Europe. Finally, there are budget freelancers, they are inexpensive and usually in parts of Asia and South America.
|
||||
|
||||
I am going to break down the pros and cons of each of these options.
|
||||
|
||||
### Agency
|
||||
|
||||
Agencies are often a safe bet if you're looking for a more hands-off approach agencies are often the way to go, they have project managers who will manage your project and communicate your requirements to developers. This takes some of the work off of your plate and can free it up to work on your app. Agencies also often have a team of developers at their disposal, so if the developer working on your project takes a vacation, they can swap another developer in without much hassle.
|
||||
|
||||
With all these upsides there is a downside. Price. Having a sales team, a project management team, and a developer team isn't cheap. Agencies often cost quite a bit of money compared to freelancers.
|
||||
|
||||
So in summary:
|
||||
|
||||
#### Pros
|
||||
|
||||
* Hands Off
|
||||
* No Single Point of Failure
|
||||
|
||||
|
||||
|
||||
#### Cons
|
||||
|
||||
* Very expensive
|
||||
|
||||
|
||||
|
||||
### Market Rate Freelancer
|
||||
|
||||
Another option you have are market rate freelancers, these are highly skilled developers who often have worked in agencies, but decided to go their own way and get clients themselves. They generally produce high-quality work at a lower cost than agencies.
|
||||
|
||||
The downside to freelancers is since they're only one person they might not be available right away to start your work. Especially high demand freelancers you may have to wait a few weeks or months before they start development. They also are hard to replace, if they get sick or go on vacation, it can often be hard to find someone to continue the work, unless you get a good recommendation from the freelancer.
|
||||
|
||||
#### Pros
|
||||
|
||||
* Cost Effective
|
||||
* Similar quality to agency
|
||||
* Great for short term
|
||||
|
||||
|
||||
|
||||
#### Cons
|
||||
|
||||
* May not be available
|
||||
* Hard to replace
|
||||
|
||||
|
||||
|
||||
### Budget Freelancer
|
||||
|
||||
The last option I'm going over is budget freelancers who are often found on job boards such as Fiverr and Upwork. They work for very cheap, but that often comes at the cost of quality and communication. Often you will not get what you're looking for, or it will be very brittle code which buckles under strain.
|
||||
|
||||
If you're on a very tight budget, it may be worth rolling the dice on a highly rated budget freelancer, although you must be okay with the risk of potentially throwing the code away.
|
||||
|
||||
#### Pros
|
||||
|
||||
* Very cheap
|
||||
|
||||
|
||||
|
||||
#### Cons
|
||||
|
||||
* Often low quality
|
||||
* May not be what you asked for
|
||||
|
||||
|
||||
|
||||
### Conclusion
|
||||
|
||||
Getting the right backend for your app is important. It is often a good idea to stick with agencies or market rate freelancers due to the predictability and higher quality code, but if you're on a very tight budget rolling the dice with budget freelancers could pay off. At the end of the day, it doesn't matter where the code is from, as long as it works and does what it's supposed to do.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://ryanmccue.ca/where-to-get-your-app-backend-built/
|
||||
|
||||
作者：[Ryan McCue][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://ryanmccue.ca/author/ryan/
|
||||
@ -1,43 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
What is the deal with GraphQL?
|
||||
======
|
||||
|
||||
|
||||
|
||||
There has been lots of talks lately about this thing called [GraphQL][1]. It is a relatively new technology coming out of Facebook and is starting to be widely adopted by large companies like [Github][2], Facebook, Twitter, Yelp, and many others. Basically, GraphQL is an alternative to REST, it replaces many dumb endpoints, `/user/1`, `/user/1/comments` with `/graphql` and you use the post body or query string to request the data you need, like, `/graphql?query={user(id:1){id,username,comments{text}}}`. You pick the pieces of data you need and can nest down to relations to avoid multiple calls. This is a different way of thinking about a backend, but in some situations, it makes practical sense.
|
||||
|
||||
### My Experience with GraphQL
|
||||
|
||||
Originally when I heard about it I was very skeptical, after dabbling in [Apollo Server][3] I was not convinced. Why would you use some silly new technology when you can simply build REST endpoints! But after digging deeper and learning more about its use cases, I came around. I still think REST has a place and will be important for the foreseeable future, but with how bad many APIs and their documentation are, this can be a breath of fresh air...
|
||||
|
||||
### Why Use GraphQL Over REST?
|
||||
|
||||
Although I have used GraphQL, and think it is a compelling and exciting technology, I believe it does not replace REST. That being said there are compelling reasons to pick GraphQL over REST in some situations. When you are building mobile apps or web apps which are made with high mobile traffic in mind GraphQL really shines. The reason for this is mobile data. REST uses many calls and often returns unused data whereas, with GraphQL, you can define precisely what you want to be returned for minimal data usage.
|
||||
|
||||
You can get do all the above with REST by making multiple endpoints available, but that also adds complexity to the project. It also means there will be back and forth between the front and backend teams.
|
||||
|
||||
### What Should You Use?
|
||||
|
||||
GraphQL is a new technology which is now mainstream. But many developers are not aware of it or choose not to learn it because they think it's a fad. I feel like for most projects you can get away using either REST or GraphQL. Developing using GraphQL has great benefits like enforcing documentation, which helps teams work better together, and provides clear expectations for each query. This will likely speed up development after the initial hurdle of wrapping your head around GraphQL.
|
||||
|
||||
Although I have been comparing GraphQL and REST, I think in most cases a mixture of the two will produce the best results. Combine the strengths of both instead of seeing it strightly as just using GraphQL or just using REST.
|
||||
|
||||
### Final Thoughts
|
||||
|
||||
Both technologies are here to stay. And done right both technologies can make fast and efficient backends. GraphQL has an edge up because it allows the client to query only the data they need by default, but that is at a potential sacrifice of endpoint speed. Ultimately, if I were starting a new project, I would go with a mix of both GraphQL and REST.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://ryanmccue.ca/what-is-the-deal-with-graphql/
|
||||
|
||||
作者：[Ryan McCue][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://ryanmccue.ca/author/ryan/
|
||||
[1]:http://graphql.org/
|
||||
[2]:https://developer.github.com/v4/
|
||||
[3]:https://github.com/apollographql/apollo-server
|
||||
@ -1,109 +0,0 @@
|
||||
5 Real World Uses for Redis
|
||||
============================================================
|
||||
|
||||
|
||||
Redis is a powerful in-memory data structure store which has many uses including a database, a cache, and a message broker. Most people often think of it a simple key-value store, but it has so much more power. I will be going over some real world examples of some of the many things Redis can do for you.
|
||||
|
||||
### 1\. Full Page Cache
|
||||
|
||||
The first thing is full page caching. If you are using server-side rendered content, you do not want to re-render each page for every single request. Using a cache like Redis, you can cache regularly requested content and drastically decrease latency for your most requested pages, and most frameworks have hooks for caching your pages with Redis.
|
||||
Simple Commands
|
||||
|
||||
```
|
||||
// Set the page that will last 1 minute
|
||||
SET key "<html>...</html>" EX 60
|
||||
|
||||
// Get the page
|
||||
GET key
|
||||
|
||||
```
|
||||
|
||||
### 2\. Leaderboard
|
||||
|
||||
One of the places Redis shines is for leaderboards. Because Redis is in-memory, it can deal with incrementing and decrementing very fast and efficiently. Compare this to running a SQL query every request the performance gains are huge! This combined with Redis's sorted sets means you can grab only the highest rated items in the list in milliseconds, and it is stupid easy to implement.
|
||||
Simple Commands
|
||||
|
||||
```
|
||||
// Add an item to the sorted set
|
||||
ZADD sortedSet 1 "one"
|
||||
|
||||
// Get all items from the sorted set
|
||||
ZRANGE sortedSet 0 -1
|
||||
|
||||
// Get all items from the sorted set with their score
|
||||
ZRANGE sortedSet 0 -1 WITHSCORES
|
||||
|
||||
```
|
||||
|
||||
### 3\. Session Storage
|
||||
|
||||
The most common use for Redis I have seen is session storage. Unlike other session stores like Memcache, Redis can persist data so in the situation where your cache goes down when it comes back up all the data will still be there. Although this isn't mission critical to be persisted, this feature can save your users lots of headaches. No one likes their session to be randomly dropped for no reason.
|
||||
Simple Commands
|
||||
|
||||
```
|
||||
// Set session that will last 1 minute
|
||||
SET randomHash "{userId}" EX 60
|
||||
|
||||
// Get userId
|
||||
GET randomHash
|
||||
|
||||
```
|
||||
|
||||
### 4\. Queue
|
||||
|
||||
One of the less common, but very useful things you can do with Redis is queue things. Whether it's a queue of emails or data to be consumed by another application, you can create an efficient queue it in Redis. Using this functionality is easy and natural for any developer who is familiar with Stacks and pushing and popping items.
|
||||
Simple Commands
|
||||
|
||||
```
|
||||
// Add a Message
|
||||
HSET messages <id> <message>
|
||||
ZADD due <due_timestamp> <id>
|
||||
|
||||
// Recieving Message
|
||||
ZRANGEBYSCORE due -inf <current_timestamp> LIMIT 0 1
|
||||
HGET messages <message_id>
|
||||
|
||||
// Delete Message
|
||||
ZREM due <message_id>
|
||||
HDEL messages <message_id>
|
||||
|
||||
```
|
||||
|
||||
### 5\. Pub/Sub
|
||||
|
||||
The final real world use for Redis I am going to bring up in this post is pub/sub. This is one of the most powerful features Redis has built in; the possibilities are limitless. You can create a real-time chat system with it, trigger notifications for friend requests on social networks, etc... This feature is one of the most underrated features Redis offers but is very powerful, yet simple to use.
|
||||
Simple Commands
|
||||
|
||||
```
|
||||
// Add a message to a channel
|
||||
PUBLISH channel message
|
||||
|
||||
// Recieve messages from a channel
|
||||
SUBSCRIBE channel
|
||||
|
||||
```
|
||||
|
||||
### Conclusion
|
||||
|
||||
I hope you enjoyed this list of some of the many real world uses for Redis. This is just scratching the surface of what Redis can do for you, but I hope it gave you some ideas of how you can use the full potential Redis has to offer.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介:
|
||||
|
||||
Hi, my name is Ryan! I am a Software Developer with experience in many web frameworks and libraries including NodeJS, Django, Golang, and Laravel.
|
||||
|
||||
|
||||
-------------------
|
||||
|
||||
|
||||
via: https://ryanmccue.ca/5-real-world-uses-for-redis/
|
||||
|
||||
作者：[Ryan McCue ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://ryanmccue.ca/author/ryan/
|
||||
[1]:https://ryanmccue.ca/author/ryan/
|
||||
Loading…
Reference in New Issue
Block a user