Elastic Search always returns top 10 results by default. To get large volume of results, we need to user Search API.
The Search API provides
size parameters that can be used to retrieve predefined amount of data. But using from and size should be avoided to request very large volume at once. Reason: Search request works with multiple shards storing its requested hits into memory which leads into high memory + CPU usage.
Internationalization is a basic feature for web apps having users from different corners of the world.
vue-i18n makes the process very smooth to implement internationalization into VueJs web apps. Poeditor is another tool that provides a smooth translation workflow.
Recently I ‘d a chance to migrate the Vue application (with local translation data) to make it work with Poeditor’s API.
In case you don’t know about poeditor. It provides a smooth translation workflow. And also
For more details visit poeditor.
The technique mentioned in this article…
This article originally appeared 4 years ago at
It was re-written for the demonstration of an awesome tool RamroCode. Hope you like the beautiful code snippets 🙂
Authorization is a basic feature of modern web applications. It’s a mechanism of specifying access rights or privileges to resources according to user roles. In case of CMS like applications, it needs to be equipped with advanced libraries and authorization techniques. But for minimal applications a full fledged library can be an overhead.
I will discuss a dead simple authorization technique based on HTTP verbs, for this particular purpose.
This technique isn’t something you can implement anywhere. Use this only if your requirements match the particular scenario.
DynamoDB is a NoSql database and models data in Table-Items-Attributes structure. It allows data-item to be schema less. It’s a huge advantage as it allows you to write data in any format as desired. Even if structure of your data changes eg: a new field is added/deleted at later point of time, it adapts to it well.
With freedom of schema flexibility, data format inconsistency comes alongside. Even if database provides the power of flexibility, the schema shouldn’t change to that point at which it affects the performance of the system. It becomes an overhead to write separate business logic…
Its a very basic requirement for applications to delete data item from the database after it has no use. Certain information like verification code, one time passwords, gift coupons, activation keys etc. don’t need to be stored once used. Typically, a cron job can be scheduled to get rid of such data items at certain intervals. But modern databases have this feature built onto the system.
Dynamodb provides a TTL field to achieve this goal. Dynamodb docs states that
Amazon DynamoDB Time to Live (TTL) allows you to define a per-item timestamp to determine when an item is no longer…
Create a bucket with your domain name.
This post explains my recent experience regarding the endevour of implementing shared custom response from multiple controller actions in Ruby On Rails.
Lets say we have a controller. Inside it lies the following actions: action_1, action_2, action_3 and action_4. All of these actions would respond with custom response and for convenience the responses will be in JSON format. We need to send the same custom response from different actions, thus the response needs to be shared.
Such scenarios my arise when:
Serializers allow complex data like database query results and model instances to be converted to native Python data types which can then be easily rendered into JSON content types. It also provide deserialization, i.e. validating and then converting JSON data back into complex types.
Multiple SeriaizerMethodField() needs to access a same resource in Database. One easier way is to get the resource from DB at each get_<fieldname> method. It works fine but getting same resource again and again from DB is not performant solution. Instead a “get_resource” function can be written to access the resource once and use it throughout…