thumbnail_stacked-logs-2.png

stacked-logs-2.png

It's a logical question, given the amount of data we're collecting with Resurface API logging. The answer is no. You don't need a DBA. Let's dive into why this is the case.

## Self-managing tables, storage and replication

Resurface includes all of the database components that you need, so you don't need a DBA to create tables, manage indexes, or schedule backups. Resurface includes Apache Pulsar, which allows data to be reliably stored and replicated without any regular maintenance. You can define specific quotas for storage and retention, or simply allow the database to grow to fit the storage available. Your oldest data will be automatically removed as new data arrives. Need higher reliability? Add nodes across multiple datacenters or cloud providers and your data will be automatically replicated across your cluster.


## Built on Docker and Kubernetes

Resurface is built to scale horizontally in a hosted environment with fully Dockerized containers. Orchestration with Docker Compose and Kubernetes are both supported, so large distributed clusters are easy to operate. So record it all. Even if that's tens or hundreds of TBs. Since Resurface is deployed inside your virtual private cloud (VPC), you're always in control of your data.

![blog-2020-18b.jpg](https://res.cloudinary.com/dgk9bfuhq/image/upload/v1601880410/blog_2020_18b_e68a9a299e.jpg)


## Presto admin console

Resurface includes Apache Presto as our SQL query engine. Presto offers a simple UI to allow you to see what queries are running, queued, or even those that have failed. It isn't quite as extensive as what's included in Oracle or Microsoft SQL Server — but allows you to see every query being executed against your Resurface database, regardless of what application ran the SQL query.

![blog-2020-18a.jpg](https://res.cloudinary.com/dgk9bfuhq/image/upload/v1601880520/blog_2020_18a_75e9305cbe.jpg)


## See for yourself

Sign up for a demo to see how easy it is to manage API logging with Resurface. Completely within your VPC. Without ever needing a DBA.


<a class="btn btn-primary my-3" href="https://resurface.io/calendly" target="_blank">Schedule Your Demo</a>



Will You Need a DBA?

thumbnail_stacked-logs-1.png

stacked-logs-1.png

SaaS makes sense to manage server costs, launch large workloads and allow you to scale up or down. But handing off your critical data to a third-party SaaS is increasingly risky and complicated, when self-hosted solutions are getting cheaper and easier to run.

## The risk of privacy fatigue

IronCore's CEO, Patrick Walsh <a href="https://blog.ironcorelabs.com/warning-saas-privacy-debt-will-crush-your-roadmap-3869e79e3105?gi=88c98375b9" target="_blank">recently wrote a compelling argument</a> about not overlooking SaaS data privacy. He advocates not treating this as acceptable technical debt:

**Your data now requires extra protection, tracking, minimization, data retention, transparency around sharing and selling, and much more. Privacy laws tend to use broad but largely undefined terms and phrases like, "data protection by design and by default" without specifying what does or doesn't qualify as sufficient protection or sufficient design.**

Hit replay for a second when all things were SaaS. It makes a lot of sense to reduce server costs, manage large workloads and allow you to scale up or down. Yes, please. But now, we've added a new facet to consider: Where is your critical data living? This question is one that we need to ask ourselves. And, perhaps more importantly, it's one that our customers and partner ask of us. How are you protecting personally identifiable information (PII)? We all have to contemplate the tradeoffs with privacy and security. And, as Walsh says, "there's a significant privacy burden and fatigue" from the issue.

## Don't pay with your data

Evan Grabiner, founder and CEO of Aspecto (admittedly the AWS eco-system) puts a finer point on the issue in his [article:](https://medium.com/@eran_80147/is-data-privacy-killing-saas-2bbd096b1460)

**Natively, SaaS solutions require organizations to move data out of their hands, to the solution provider, with the result that organizations needed to trust a third-party service provider with their sensitive data, at the same time GDPR is telling them not to.**

Although Evan advocates for a virtual private cloud (VPC), I think there's another way. And we've built our technology to balance the need for data privacy with the need for, well, data.

Look at it this way, who do you want to have and use your data? These large SaaS platforms consume large amounts of your own data, on top of what you're already paying for usage. While you may think you're paying for data, I argue you're paying with your data. Logical considerations about privacy and compliance aside, the fact is, the one set of data you want to own and manage is your customer data.

## Own your data

First-party data stewardship is a founding principle at Resurface. Yes, we want to better understand how customers are using APIs, but we've also designed for information protection. Deep monitoring without a privacy-infringing footprint. Out customers own every bit of the entire API interaction – down to the granular individual detail. We're all about data independence, first-party data ownership, and customer-centric data management.

So, yes, SaaS isn't going anywhere. But it's worth looking at the kinds of data you're shipping to a third-party to ensure you can stay on top of ever-changing privacy regulations, and know the most about the customers you want to keep.

## See for yourself

Sign up for a demo to see how easy it is to monitor API calls with Resurface. Because your data is too valuable to share.


<a class="btn btn-primary my-3" href="https://resurface.io/calendly" target="_blank">Schedule Your Demo</a>


Why the Pendulum is Swinging Away From SaaS

thumbnail_stacked-logs-3.png

stacked-logs-3.png

GraphQL adopters are quickly realizing that APM and logging tools built for REST-style APIs are not a great fit. But for Resurface, native GraphQL support is an obvious next step to unlocking insights for customers.

## Why traditional monitoring falls short

With GraphQL, every request URL is the same, and it doesn't make sense to lump performance of all of these together. Response codes are not meaningful either. Visibility into request and response bodies is critical to understand what's really going on in production.

Given that Resurface excels at processing request and response body data, providing native GraphQL support is an obvious next step. The goal is to help customers understand what GraphQL queries are the most heavily used, where performance optimizations are needed, and how field usage changes over time. Resurface provides this visibility without ever transferring data a third party like services from Moesif and Apollo.

## GraphQL won't dominate overnight

A key observation is that many GraphQL adopters still expect to have their older REST-style APIs for years to come. Even the most enthusiastic adopters aren't setting the goal of converting overnight. This is an area where Apollo is particularly weak — Apollo only understands GraphQL traffic and provides no help for legacy REST APIs. Adopting Resurface yields visibility into both GraphQL-style and REST-style APIs, which is important since many customers will be using those in concert for some time.

## Our product roadmap for GraphQL

The first piece of our GraphQL story shipped this week — our <a href="https://www.npmjs.com/package/resurfaceio-logger" target="_blank">Node.js logger v2</a>  now integrates with Apollo Server to capture GraphQL requests and responses, which allows Resurface to function as a commercial alternative to the Apollo Trace Warehouse.

Next we're working towards GraphQL extensions for data privacy & security in our loggers, plus native GraphQL indexes and query functions in our database. But more importantly, we're excited to join the fray in the growing GraphQL community, with its highly progressive segment of API developers, and its obvious disruption for entrenched APM vendors.



Why Native GraphQL Support Really Matters

thumbnail_stacked-logs-4.png

stacked-logs-4.png

## Changes in v2 loggers

- Logging response time intervals (as seen by middleware)
- Counting submit successes and failures
- Loading rules from local files
- Performance and efficiency optimizations
- Move message generation logic into HttpMessage.send
- Consolidate rules management and parsing into HttpRules
- Upgrade language & package dependency versions (for security and LTS)

## Upgrading to v2 loggers

If you're using one of our middleware classes (like HttpLoggerForServlets for Java, or HttpLoggerForExpress for Node.js), then you won't have to make any application changes except to reference the latest library version. If you're using the logger API directly, then refer to the API documentation links above for details.

Latest API docs

- <a href="https://github.com/resurfaceio/logger-java/blob/master/API.md" target="_blank">Java logger</a>
- <a href="https://github.com/resurfaceio/logger-nodejs/blob/master/API.md" target="_blank">Node.js logger</a>
- <a href="https://github.com/resurfaceio/logger-python/blob/master/API.md" target="_blank">Python logger</a>
- <a href="https://github.com/resurfaceio/logger-ruby/blob/master/API.md" target="_blank">Ruby logger</a>

2.0 Releases for All Loggers

thumbnail_stacked-logs-5.png

stacked-logs-5.png

The design for our 2.x logging API has been in the works for the last few months. Our NodeJS logger is the first to reach this exciting milestone.

## Changes in this release

- Added support for GraphQL logging with Apollo/Express <a href="https://github.com/resurfaceio/logger-nodejs#logging_from_apollo_server_on_express" target="_blank">(more information)</a>
- Revised error handling, with promises that complete even if errors occurred
- Made improvements and fixes to Express logging middleware
- Simplified internal APIs for rules and message generation
- Added support for logging response times

## Efficiency improvements

Logging overhead in this release has been significantly reduced by moving rules processing, JSON conversion and data transmission to the background.

## Code and docs on GitHub

Our Node.js logger is an open source library, licensed under the Apache 2 license. All sources and documentation are available on <a href="https://github.com/resurfaceio/logger-nodejs" target="_blank">GitHub</a>.

As an open project, bug reports and pull requests from outside contributors are welcome!

## Installing with npm

Binary packages are available on <a href="https://www.npmjs.com/package/resurfaceio-logger" target="_blank">npm.js</a> for easy installation.

<pre class="p-3"><code>npm install resurfaceio-logger --save</code></pre>


NodeJS Logger 2.0 Release

thumbnail_stacked-logs-8.png

stacked-logs-8.png

Loggers can now load logging rules from local files, using either relative or absolute paths. This makes groups of rules easier to develop and share between apps.

## Why load from files?

Logging rules have (before now) always been specified in-line as part of configuring a logger. Our thinking was that the rules would then always been in sync with the application itself. But this can be tedious to have to rebuild/redeploy your API service just to try a tweak to the logging rules. And externalizing rules into files unlocks new ways to share sets of rules between applications.

## Examples

The path to the rules file can be either absolute or relative.

<pre class="p-3"><code>// Java example
logger = new HttpLogger("https://...", "file://./rules.txt");

# Node.js example
logger = new HttpLogger({url: 'https://...', rules: 'file://./rules.txt'});</code></pre>


## Supported logger versions

- <a href="https://github.com/resurfaceio/logger-java" target="_blank">Java logger</a> - 1.10.1 and up
- <a href="https://github.com/resurfaceio/logger-nodejs" target="_blank">Node.js logger</a> - 2.0.1 and up
- <a href="https://github.com/resurfaceio/logger-python" target="_blank">Python logger</a> - 2.0.1 and up
- <a href="https://github.com/resurfaceio/logger-ruby" target="_blank">Ruby logger]</a> - 2.0.1 and up


Loading Rules from Local Files

thumbnail_stacked-logs-7.png

stacked-logs-7.png

All loggers now automatically capture host names, allowing request and response data to be pivoted by the host that handled the request.

## Logging host names

All loggers now capture the name of the system with each request, by looking for known environment variables or by looking up the local hostname. Host names are then available in the Resurface database for querying. This is completely automatic and requires no configuration changes.

## Supported logger versions

- <a href="https://github.com/resurfaceio/logger-java" target="_blank">Java logger</a> - 1.10.0 and up
- <a href="https://github.com/resurfaceio/logger-nodejs" target="_blank">Node.js logger</a> - 1.10.0 and up
- <a href="https://github.com/resurfaceio/logger-python" target="_blank">Python logger</a> - 0.6.0 and up
- <a href="https://github.com/resurfaceio/logger-ruby" target="_blank">Ruby logger</a> - 1.10.0 and up

Logging Host Names

thumbnail_stacked-logs-6.png

stacked-logs-6.png

Logging real usage of Django-based APIs is now easy as pie with our native Python3 logger. Installation and configuration for Django services takes just a few minutes.

## Code and docs on GitHub

Our Python logger is an open source library, licensed under the Apache 2 license. All sources and documentation are available on GitHub.

As an open project, bug reports and pull requests from outside contributors are welcome!

## Installing from PyPi

Binary packages are available on <a href="https://pypi.org/project/usagelogger" target="_blank">PyPi</a> for easy installation.

<pre class="p-3"><code>pip install --upgrade usagelogger</code></pre>

## Logging rules

Our Python logger supports all the same <a href="https://resurface.io/rules.html" target="_blank">logging rules</a> as our other libraries, allowing these rules to be shared easily across applications.

## Integration with Django

Simply edit your settings.py file to install the Django logger. That's it!


<pre class="p-3"><code>MIDDLEWARE = [
    "django.middleware...",
    "usagelogger.django.HttpLoggerForDjango",
]</code></pre>


Logging with Python and Django

thumbnail_stacked-logs.png

stacked-logs.png

#### Our friends at New Relic claim that "uptime is everything." And on the surface, that might feel right. If your systems aren't available or responding quickly, your customers will obviously be impacted. But measuring uptime is not enough to understand how well your APIs are serving your customers.


<h2>The complexity problem</h2>

Many modern APIs have to handle a complex variety of inputs and outputs, while correctly maintaining their internal state. A side effect of this high level of complexity is difficulty in proving that the API will properly handle every possible case. Even for a relatively simple API, there may be hundreds if not thousands of cases that have to be verified. It is increasingly common to see systems that are "available" yet have specific cases that fail badly.


<h2>Logic failures are costly</h2>

One example that we've seen up close was a major e-commerce vendor who put out a new version of their API, only to find that sales volume inexplicably dropped afterward. All automated tests had passed in pre-production. None of their system-oriented monitoring tools in production were reporting any problems. They spent several weeks trying to find this problem.

Turns out the failure could be traced to an error that occurred only when there was a trailing zero in a customer's zip code. Customers from these unfortunate zip codes could not complete their purchases, since their zip codes were considered invalid. This resulted in a six percent loss of revenue — millions of dollars in revenue — all because of one failed routine.

The best part about this story is that we were able to identify all of the affected customers, particularly customers who abandoned their orders without ever reporting a problem. We reached out to each customer with an apology and a discount code to return. Needle found, problem solved, and revenue recovered.


<h2>Synthetics don't cover all cases</h2>

Synthetic monitoring tools make the promise that they will alert you to problems before your customers do. But in reality, synthetics only measure the correctness of specific paths through the API. This is just another way of measuring system availability. It's prohibitive to create synthetic scripts that exercise every possible combination of inputs, outputs and internal state.


<h2>Resurface records all inputs and outputs</h2>

With Resurface, you'll have a system of record for all API calls — through a one-time configuration of logging middleware. Without having to define and maintain synthetic scripts. Without having to assume that system health equates to customer success in all cases.

So, the next time you hear "uptime is everything," think twice before nodding your head. Because your systems might be running, but you probably still have cases where customers are failing or frustrated. You just can't see them.

Yet.

For more details, see how Resurface compares to <a href="/vs_apm">APM</a> and <a href="/vs_synthetics">synthetic monitoring</a> tools. Or sign up for a demo to see how easy it is to turn every API call into an observable transaction. Because uptime is not enough.


<a href="https://calendly.com/robfromresurfaceio" target="_blank" class="btn btn-primary my-3">Schedule Your Demo</a>


Is Uptime Really Everything?

small_headless.jpg

thumbnail_headless.jpg

headless.jpg

I’m a big believer in data-driven decisions, but the reality is sometimes we’re less data-driven than we’d like. Other powerful factors can drive decisions. Like going with what you know vs. what the data tells you. When choosing our CMS, should we go with the known or the harder path?

We chose the harder path.

Resurface is an API-first company, changing the way APIs are monitored and optimized. So, it stands to reason that we’d make all decisions based on that mantra. But when it came to our website, we were faced with a decision on how it’s architected. WordPress was the easy choice, it’s well-known, reasonably priced to run, and offers a plethora of plug-ins and available skillsets.

But we wouldn’t be able to run Resurface on our site. And, it’s not API-first technology.

So, back to data-driven. I created a spreadsheet to weigh the varying website alternatives by different factors. Admittedly, the weighting was subjective, highlighting what we deemed critical, and what was nice-to-have. Here’s the list (we did not include what we considered table stakes):
<br>

![headless-table.png](https://res.cloudinary.com/dgk9bfuhq/image/upload/v1604458599/headless_table_bae4e663d3.png)


The ensuing discussion was powerful, as it really led us to evaluate all facets, and recognize the tradeoffs with each. In the end, headless won, swayed by API-first and the ability to leverage our own software. Frankly, I couldn’t fathom explaining to our users why we weren’t using our own tech. Even if it meant we were boldly going into a new world.

We were now on our own for discovery and some of the required integrations. The easy answer would have been to follow what we knew, the paved path. But that would have been in opposition to our prime directive.

We found a great partner in  <a href="https://www.webriq.com/">**WebriQ**</a>, who worked closely with our own React developer to make it all happen. Oh, and I forgot one small detail: We needed the new site revamped and live in just a few weeks to align with our planned funding announcement.

Go time.

We had our copy ready, a few ideas, and a realistic expectation of what was – and wasn’t – in scope.  <a href="https://www.webriq.com/">**WebriQ**</a> to the rescue with fast response times, and an easy way to interact via a dedicated Slack channel and direct task visibility in Zoho. We iterated and partnered throughout. A dream arrangement for on-the-fly decisions and reviews that surfaced more ideas and issues.

The night before our announcement, we pushed live (owning our DNS). Now we have a fast, agile website that we can quickly evolve to take advantage of headless – publish anywhere, personalize and truly run API-first.

So, yes to headless. Stay true to what’s important, and do not fear the unknown. (And if you have tips and tricks running headless, we’re all ears. Metaphorically speaking, of course.)



Tale of the Whale

Deep visibility into your APIs

Why we went headless