Introduction to CouchDB with .NET part 4: continuing with the CouchDB HTTP API


In the previous post we started looking into the CouchDB HTTP Web API. The API allows us to communicate with the CouchDB server using HTTP calls. This and the ubiquitous JSON arguments make integration with CouchDB quite straightforward for all platforms that are capable to execute HTTP calls and surely any serious programming language should be equipped with web request execution. The HTTP API responds with JSON by default and that also makes for a seamless integration.

We have primarily looked at various requests that did not modify the database or the documents. In this post we’ll continue with testing the database and document modification endpoints in the API.

Read more of this post

Introduction to CouchDB with .NET part 3: starting with the CouchDB HTTP API


In the previous post we looked at the CouchDB administrative UI called Fauxton. The UI that shipped with earlier versions of CouchDB is called Futon so you will still come across that name if you work with older CouchDB projects. Fauxton is quite easy and straightforward to use. The database section allows us to create, update and delete databases and documents. Many functions are meant to be handled by database admins such as CouchDB users, access rights, processes and configuration.

In this post we’ll start exploring the CouchDB HTTP-based API.

Read more of this post

Introduction to CouchDB with .NET part 2: Fauxton UI basics


In the previous post we laid the foundations for this series. We’ll discuss the basics of the NoSql document-based data store CouchDB. CouchDB stores its records in documents as JSON which makes integration with clients relatively easy. CouchDB comes with a web-based administrative UI that allows us to create databases, check their content, create users, administrators and many other things that we’ll eventually cover in this series. CouchDB is completely schemaless, has no data integrity checks and its JSON storage format allows us to store our domain objects in a more natural way than table-based relational databases do.

We successfully installed CouchDB on Windows. It was a straightforward and painless experience. The installer also set up a Windows Service so that the CouchDB server is up and running all the time. We had to solve one issue though after the initial setup: 3 administrative databases were not installed and we had to create them in the UI. In the absence of those tables the CouchDB server keeps logging the same exception message in the log file.

In this post we’ll be looking into various basic functions in the CouchDB management UI called Fauxton.

Read more of this post

Introduction to CouchDB with .NET part 1: foundations and setup


CouchDB is a document based NoSql database by Apache written mostly in the Erlang programming language with C and C++ added in. It is also open-source and free-of-charge in both hobby and real-life commercial projects. If you’ve only worked with traditional relational databases like MS SQL with its tables, schemas, integrity checks, primary and secondary keys etc. then a document database will require a significant shift in the way you think of storing data. CouchDB shares a number of traits with MongoDB which is the most popular document based data store at this time. Both CouchDB and MongoDB store their data in documents, they don’t have any strictly enforced schema and no strict data integrity by way of secondary keys. They can both store our domain objects “as they are”, without the need of designing tables for them. In other words CouchDB represents our domain objects much closer than table-based relational databases can do. CouchDB and MongoDB can run on both Linux and Windows. Also, they can be clustered with in a master-slave setup with a primary database serves as the read/write node and the secondary databases all share the read-load. The master is then responsible for replicating data modifications such as inserts, updates and deletes to the secondary nodes.

CouchDB comes with a built-in management tool where we can view our databases and documents, edit them, delete them and perform a range of other administrative tasks. Relational databases are still the norm and the primary choice among developers for the data storage needs for their projects. However, it’s always good to know that there are alternatives that offer alternative ways of storing data. Both CouchDB and MongoDB provide fast read and write operations. CouchDB offers a REST API based query interface with the usual HTTP verbs like GET, PUT, DELETE etc. Querying can be performed with either predefined views or a new query language called Mango that was added to CouchDB 2.0.

In this series we’ll be looking at the basics of CouchDB, how to set it up on Windows, how to insert data, how to execute queries and finally how to communicate with a CouchDB database from your .NET project.

Read more of this post

Using the Redis NoSql database with .NET Part 18: Redis as a cache engine in .NET


In the previous post we looked briefly at data persistence in Redis. We know that the principal storage for Redis is the memory. It also offers two modes of persistence. The first option is called snapshotting which means that the database is saved to disk periodically. The periodicity can be configured in the Redis config file and we can define multiple options depending on the number of new items in memory. The drawback of snapshotting is that if the Redis service abruptly goes down then some unsaved data in memory will be lost. If you cannot afford any data loss then the append-only persistence mode can be for you. It saves the commands in an append-only file which is processed when Redis starts up to restore the database based on the saved commands. Note that append-only will make write operations slower.

In this post we’ll look at caching in the ServiceStack.Redis client. This post also concludes the series on Redis with .NET.

Read more of this post

Using the Redis NoSql database with .NET Part 17: persistence


In the previous post we looked at the security features of Redis. We saw that Redis doesn’t come with the highly granular security features of a full-fledged relational database like SQL Server or Oracle. It offers password passed authentication where the client needs to authenticate with a password before issuing commands. There’s no separate username and we cannot set granular rules like userA can only access this and this resource. Another security feature is command obfuscation where we can change how a command is called. The CONFIG command can be a “dangerous” one that we don’t want just any user to be able to call. We can instead provide another name, possibly a cryptic one, for it so that CONFIG must be called by that name instead.

In this post we’ll discuss the persistence options in Redis.

Read more of this post

Using the Redis NoSql database with .NET Part 16: security


In the previous post we looked at how to log slow queries in Redis. We can declare the limit using the slowlog-log-slower-than flag that accepts an integer. If a query whose execution time exceeds this limit expressed in microseconds is logged to the slow log. The slow log is persisted only in memory and we can set an upper limit to the number of commands stored there. If this limit is reached then the oldest stored command is removed.

In this post we’ll see what Redis has to offer by way of security.

Read more of this post


A great site

iReadable { }

.NET Tips & Tricks

Robin Sedlaczek's Blog

Developer on Microsoft Technologies

HarsH ReaLiTy

A Good Blog is Hard to Find

Softwarearchitektur in der Praxis

Wissenswertes zu Webentwicklung, Domain-Driven Design und Microservices

the software architecture

thoughts, ideas, diagrams,enterprise code, design pattern , solution designs

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

Anything around ASP.NET MVC,WEB API, WCF, Entity Framework & AngularJS

Cyber Matters

Bite-size insight on Cyber Security for the not too technical.

Guru N Guns's

OneSolution To dOTnET.

Johnny Zraiby

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

%d bloggers like this: