Category: Discipline

Categories
Blockchain Financial Services

Introducing Gardener, our homegrown Ethereum oracle

If smart contracts and blockchain technology are going to disrupt anything, they need a way to speak to the outside world. Also known as the blockchain oracle problem, blockchains can’t gather off-chain data without help. Enter the Ethereum oracle — or a way to connect smart contracts with outside information. Until now, there are only a few blockchain oracles on the market, each with limitations — and none for free. Espeo Blockchain development team has changed that. We’ve just launched the first open-source Ethereum oracle, Gardener. At Espeo we strongly believe in transparency and would like to share the code with you. 

Gardener

Before we get into the Ethereum oracle, and the blockchain oracle problem, let’s start with a metaphor that I think captures what oracles do. Imagine a big, beautiful garden with lots of plants. But they’re not everyday plants. Instead, they can talk to each other and they thrive on information. Unfortunately, the garden is surrounded by a high wall, so no one inside can see over it.

Lucky for the plants, there is a gardener, who comes in to take care of them — and fill them in on what’s happening outside. The plants trust everything that the gardener says, and he also feels the responsibility since the information he passes to the plants is their only version of the truth about the world beyond the walls.

Sometimes the plants get suspicious and want the gardener to prove what he says. Let’s say they want to know if any apples grow outside. They want to see an apple from the other side.

Of course, the gardener has to bring an apple with him in order to convince the plants that he’s telling the truth. The gardener knows he can’t lie. If the plants demand proof and discover he’s lying, they would never trust him again and he would lose all his friends in the garden. Living in a state of symbiosis, the plants need the gardener to get information about the outside world and the gardener needs the plants’ trust to keep his job. 

Now switch the walled garden for the blockchain oracle problem, the plants for smart contracts, and the gardener for the Ethereum oracle.

The blockchain oracle problem

Even though it may sound like the plot of a children’s book, our fictional garden demonstrates a few key things about oracles and the problems they address. An oracle in blockchain terminology is an off-chain solution, which acts as a trusted user for a smart contract, which can feed it with data it needs — just like the gardener.

For a deeper dive into the Ethereum oracle topic, you can read my previous article here.

During multiple blockchain development projects at Espeo, we hit the same problem. Smart contracts can cooperate with each other but they have one serious limitation — the blockchain oracle problem. Like the plants in the walled garden, they can’t fetch anything from the world outside of their own blockchain. Do you need to check the current price of bitcoin in an Ethereum smart contract? Sorry, nope. Weather in London? Forget it. In most of our projects, we lacked a good tool to do it. So we built a solution.

Why start a new project?

In the blockchain ecosystem, there are already a few solutions to the blockchain oracle problem. The most popular is OraclizeIT, which our team found really useful. It supports many different data sources (e.g. URL, IPFS, random, computation). It met our expectations in terms of functionality and we used it in our first implementations.

Another very promising solution is Chainlink. It’s flexible and capable of providing almost any input data to the smart contract and generating an output for other blockchains, payments, etc… The biggest problem, however, is that it only lives on a test network and isn’t ready for production use quite yet.

TownCrier is another solution from Cornell University developers. Their strong academic background results in a completely different approach using Trusted Execution Environment — Intel SGX in particular. This approach guarantees that no one can alter data during processing, because the whole process lives in a safe enclave, which isn’t accessible from any other process or area.

A drawback of this solution is that it has very limited functionality and hasn’t been updated for a while. Chainlink recently acquired TownCrier so it seems things may start to move forward but most probably we’ll still need to wait for a fully functional production-ready solution.

Of course, these solutions are only available as SaaS products and the code isn’t open-source or free for the community. Espeo Blockchain places transparency among its core values, which is especially important for blockchain solutions as that’s one of the key blockchain advantages. That’s why we decided to create our own Ethereum oracle product, which would be free and open-source for the community. In parallel to implementing current projects with OraclizeIT (to deliver them quickly), we started working on a replacement. That’s how Gardener was born.

Current State

Today we are happy to say that we have a working version we can share with you. The product is in its early days but we successfully use it internally and can’t wait to challenge it with your use cases.

What we have now:

  • Ethereum smart contracts for the oracle
  • Ethereum libraries for integrating the oracle into your contracts
  • Off-chain server written in Node.js
  • Simple monitor web application for watching what happens with the requests
  • Documentation hosted at gardener.readthedocs.io
  • A GitHub organization with MIT-licensed open source repositories ready to be cloned

Summing up, so far we’ve delivered everything you need in order to fetch any data from any public API into Ethereum smart contracts.

Roadmap

What we have for now is limited but fully functional and ready to use. However, it’s not enough for us. We have big ambitions and a plan on how to improve our solution greatly.

First, we would like to add an ETH and ERC20 based fee model. This would give Gardener instance owners the ability to decide who should pay for the request to the Ethereum oracle — them or the users creating requests. Also, it would allow instance owners to add a profit margin, if necessary.

Next, we will focus on accepting more data source types and formatting options. This step will include parsers for unstructured (binary) data, access to IPFS, random data source and access to closed APIs in a secure and safe way. We will also want to incorporate heavy computing calculation using container-based approach. All of these will give users great flexibility and no constraint in the matter of data type and source.

Later, we will focus on providing proofs to our solution, specifically Intel SGX. It will guarantee data immutability during fetching and parsing processes.

Finally, we want to move on to blockchain integrations other than the Ethereum network. We will support EOS, Hyperledger Fabric, Corda and Hyperledger Sawtooth.

The above goals are something we want to focus on the first place but we don’t exclude other improvements. If you see a particular feature lacking please drop me an email or raise an issue in our Github.

Stay Tuned

Effective blockchain projects need oracles to get data from the outside. We’ve launched the first open-source solution to the blockchain oracle problem.

This is the first article from the series on the Gardener project and we’re looking forward to hearing your feedback. All the code is MIT-licensed and you can find it on GitHub. If you have any questions or would like to get help with incorporating Gardener in your project don’t hesitate to reach me by email: krzysztof.wedrowicz@espeo.eu. Hope to hear from you soon!

Categories
Blockchain Healthcare Technology

Blockchain in healthcare: how the technology could fix the industry in 2020

If you’ve spent any amount of time in a hospital, you’ve had first-hand experience with the inefficiencies of the healthcare system. Just about everyone has a story or two about red tape. More than being irritating, this friction raises prices, lowers patient satisfaction, and can even put people’s health at risk.

Many tout the benefits of blockchain technology in healthcare data management and the overall patient experience. But let’s take a closer look. What can blockchain actually do for healthcare technology? What will it not do? Is blockchain technology a good fit?

Establishing trust in healthcare technology

Like many blockchain use cases, the first benefit for the healthcare industry is removing the need for trust. In a previous blog post, developer Michał Chatłas took a hard look at blockchain and whether it’s really worth it. “Blockchain technology is beneficial in specific industries where people can’t trust one another,” he wrote. “By design, blockchains establish trust through cryptography. Parties don’t have to trust each other or third parties.” Strong use cases exist in industries where smart contracts can help verify data. Limiting access to sensitive records is another useful feature.
Some startups have begun leveraging blockchain technology to address some healthcare data management challenges. London-based MedicalChain has developed a platform for patients to control access to their medical records. PokitDok’s DokChain hopes to facilitate data exchange across the healthcare landscape. Mediledger, meanwhile, is tracking and verifying medicine in similar ways as you might track food or airplane parts in the supply chain.

Distributed data

At first glance, distributed ledger technology appears to benefit the healthcare industry by storing patient data in all the nodes of a blockchain platform. Allowing hospitals, insurance companies, and patients access to medical records may benefit the industry as a whole. getting everyone on the same page would ease some of the industry’s pain points. Blockchain-based healthcare technologies could significantly reduce the time to track down information across systems.
Currently, patient records exist on centralized databases. It’s unclear how secure these databases are and who has access. Hackers are increasingly targeting healthcare institutions to steal valuable data. A blockchain-based platform could provide a useful tool for controlling who should, and who shouldn’t see patient data.

Patient satisfaction

Consumers would not be the only ones who benefit, however. Hospital administration could check insurance information and see which procedures are covered. Insurance companies could track procedures and automatically pay healthcare providers for services instead of waiting for someone to enter it manually. Increased efficiency and savings will, in theory, optimize the industry and pass savings to people.
Lead blockchain developer at Espeo, Krzysztof Wędrowicz offered an example of a medical emergency. “Let’s say you go on vacation and you break your leg,” he said. “It’s really hard [for the distant hospital] to get your medical history and insurance information quickly. Of course, when you have a broken leg your doctor wants to repair it as fast as possible.” The doctor may have to make quick health decisions that your insurance does not pay for.
In addition to treating a medical emergency, the hospital also needs to determine where to send the bill, or else eat the losses. This uncertainty in the system creates a lot of redundant work and could put people’s health at risk. A blockchain platform which coordinates patient records, a history of procedures, and insurance claims could greatly reduce redundancies and prevent losses. It will also improve the healthcare business model as well as patient experience.

Healthcare data management and confidentiality

However, keeping confidential medical records on a fully auditable, transparent ledger raises privacy concerns. A tech-savvy person could connect the dots. Every person accessing patient records would become a point of weakness. While no one would be able to change entries without consensus, anyone could see the entry. Seeing when and where a transaction occurred could cause significant problems for medical confidentiality.
Take abortion as an extreme example. In countries where the procedure is criminalized regardless of where the procedure occurred, investigators could find out. Even where it is legal, attackers could still use the data for malicious ends. Controlling who sees medical data and for how long through encryption is key.
Wędrowicz believes the benefits outweigh the negatives. Private, permissioned blockchains such as Hyperledger fabric or Corda would be the best fit in blockchain-based healthcare. Permissioned blockchains allow companies or consortiums of companies to set rules for who gets access to data on the blockchain. Though you would still need to trust everyone with permission.

Leveraging blockchain in healthcare

As I mentioned earlier, some startups have started to apply private blockchains in the healthcare industry. London-based startup MedicalChain aims to give patients full control over their medical data. In an interview over Telegram, communications manager, Tim Robinson explained the company offers a new paradigm of transparency to patients.
“MedicalChain safeguards sensitive information by encrypting all data through the platform,” he said. “Hyperledger Fabric provides the means for an advanced access control mechanism, so that patients can be in full control of their data and who has access to this… Every transaction will be logged on the blockchain, including the individuals who gained access to this, at what time, and what data [was accessed].”
Patients give their explicit consent and can revoke it as they wish. People can also proactively grant access to specialists or healthcare establishments in case they’re incapacitated. Of course, the decision is still the patient’s decision. “[Users] take responsibility should this not be provided, ” said Robinson.
“To mitigate the chances of access being denied in emergency situations, we can set the platform up so that permission is an opt-in service (which is much more in line with what presently happens) at the discretion of the user, as opposed to an opt-out setup, where blanketed permission is the default.”
Users’ next of kin can also grant access as long as the patient has set it up that way. Robinson contends that it is a much more patient-centric model than what currently exists. 

Lingering challenges

It’s important to remember that a blockchain is only a tool, one that would still need oversight and ethical guidelines. Determining who has access and for how long is vital in healthcare data management. Allowing healthcare professionals to quickly and easily access this information while also controlling distribution is one of blockchain’s lingering challenges.
The potential for entering false data or recording a misdiagnosis is still there, but at least data would remain in one accessible place. One specific aspect that blockchain would excel at in healthcare data management is maintaining data integrity. Unauthorized edits or deletions would not occur without a timestamp.
Forbes contributor Robert Lord wrote that one of blockchain’s advantages is that it would fight against integrity-based attacks. Careless insiders or hackers could cause patient safety issues and call an institution’s reputation into question. “Blockchain technology is an excellent counter to these integrity-based attacks, he wrote, “and it’s a good forward-looking tool we might deploy to address them.” Blockchain establishes a fully auditable immutable record of changes.

Conclusion

Healthcare’s complex web of actors makes it a compelling use case for blockchain technology. Stakeholders who don’t cooperate and who don’t necessarily trust each other could benefit from a decentralized healthcare data management platform. Blockchain could empower patients by allowing them to control access to medical records. Ensuring data integrity and making it considerably cheaper to send and receive medical data are two of the most compelling cases.
As with any new technology, there are major trade-offs to consider. While keeping medical records in one place would greatly reduce the time and cost to track it down, it also raises privacy concerns. Maintaining data integrity is one of its most powerful features blockchain tech offers so far. Savings for healthcare providers, insurance companies, and consumers could spur widespread adoption. Until then, prices will continue to rise, and patients health will suffer.

Categories
Blockchain Design Software

Designing for blockchain: How to build trust through good UX

I recently sat down with blockchain product designer, Ariel Hajbos to get his take on some essential elements of good blockchain design and some of the trends in blockchain app UX. Creating an elegant, responsive design is important in all web and mobile projects, but designing for blockchain poses new challenges. Trust-building features and even color choice are vital to an overall comfortable user experience.

Blockchain UX and UI remains a major hurdle for people to actually use the technology. In an earlier interview, blockchain consulting director, Dominik Zyskowski said good design is the key to widespread adoption. “Designers,” he said, “have to create a simple, frictionless experience to attract more users.”

So far, blockchain-based apps act much differently than traditional ones. For us who work with the underlying tech every day, it’s obvious, but if you don’t, blockchain apps may not behave as you expect. They tend to lag — and when you’re seeing charts, numbers, and of course your account balance, this can cause a lot of anxiety. Building trust through good UX is the main goal. Designing for blockchain apps involves regular feedback and trust-building features that create a pleasant user experience. Better UX will encourage more consumers to incorporate the technology into their daily lives.

Ariel Hajbos is a product designer at Espeo Blockchain and has been designing for blockchain projects during his time on the team. He started his career in graphic design and has since become integral in Espeo’s blockchain design projects such as the derivatives trading platform, CloseCross, and the mobile version of the crypto exchange, Trade. io.

In your opinion what is the most important aspect of blockchain design? What’s challenging about designing for blockchain projects?

I would say that the most important thing when designing for blockchain is that the apps often deal with financial assets — users approach these applications will a lot of distance. They’d like to get to know the apps better, know the deliverables, and know the company that built it. That’s a common thing. So it’s super important in my opinion to always design for trust. My role as a designer is to win this trust from users and communicate the ideas behind the application as well as possible so they feel comfortable using it.

The principle of designing for trust is something which is useful in other categories as well. It’s not only with blockchain, but any kind of application you build, you’d like to achieve this.

That’s an interesting point — about building trust through design. How do you do it, actually? What are some features you’ve incorporated that do this?

You don’t have to reinvent the wheel. If there are some patterns that users are familiar with that would be the very best first step. Using a design system and being consistent in your blockchain design creates this feeling that everything is sound and everything in the user interface is in its place. It’s also good to avoid jargon — you can’t assume that all your users will know it so it’s good to present things clearly. If you approach it in the proper way — if you keep in mind some things that are important in UX design in general, you can build trust.

The last thing I would say is creating a feedback loop — some kind of active guidance where users see a responsive design. Even if we build something and release it it’s only the beginning of the road so it’s important to be with the users through the whole app-building building process — and its future development. End users should feel as if they have the opportunity to leave their feedback, and that we’re listening and implementing changes.

In some of the projects that you’ve worked on, what were some common features you’ve changed?

Aesthetics, number of clicks, how the app presents data, and the general flow are some features we’ve received feedback on and changed. It’s always good to discuss those matters with the actual users too. It’s a very common thing because we work in an integrative process.  We build something, we analyze it, gather feedback, and correct it — again and again and again to reach our goal no matter what the goal is. Whether it’s a business assumption or usability.

I also encourage product owners to show the UI and UX to the people that will use their app — a demo group — and gather feedback from them.  it’s also good to clash that feedback from the business perspective and then for the user’s perspective and then get something good from that.

What aesthetic changes have end-users asked for and how does it affect blockchain design?

The applications that I built with Espeo were in general, were pretty consistent. They were focused on a goal It had to be achieved according to some of the steps. There wasn’t much space to think about adding something new. However, when we designed the Trade.io mobile application, and they were happy with the UI and UX, they requested we add additional features such as different color modes in the app. We cranked up the interface to add a dark mode and a color mode.

This wasn’t only an aesthetic decision — some of the users were accustomed to shifting between different color modes. It was easier for them to analyze data and they lacked this feature in the app before we added it. While I’m designing for blockchain apps, it doesn’t seem very important at first glance but if you start to think about it but it’s something really helpful when users have to analyze data quickly and act on it.

So it had nothing to do with how the app actually works, just how it looks?

Yes, it was only about how it looks. However, you have to remember if this is a blockchain app so we were struggling with presenting a lot of data, a lot of numbers, and a lot of charts. It’s always in the context of something positive and negative when you gain or lose assets.

For some people, different color approaches for gains and losses were less stressful. Magenta/cyan (pictured above) instead of green/red was an easier approach. It felt less stressful — more like a game. It’s a kind of user approach for such a topic. It’s not only about using a clean and simple minimalistic UI it’s not always the super idea that will satisfy all users.

What values among blockchain app users influence design do you think? I mean blockchain people skew skeptical — they don’t trust anything. How does this influence UX?

Yeah, so there are a few layers to that — first of all users have to trust the machine. It’s important that the user believes that the device is responsive And that he’s getting all the information that he needs to get. It’s also connected to blockchain technology itself.

Since it’s a decentralized technology, we have to think about why users will trust the blockchain and why blockchain technology is so important to them. These are new opportunities and it’s something very exciting. So this trust in the machine and in the algorithm is a challenge for us. Designers have to help users to trust the mechanisms blockchain technology.

Aside from blockchain itself, users have to trust the people building the applications as well. For instance, in the CloseCross app that we helped design, users predict the value of assets in the future and you have to be sure that it’s accurate and that you’ll receive your assets back. To combine those two things the trust for the application itself and the trust in the UI and the UX of the application a designer’s role is to demonstrate this trust.

Reducing cognitive load, guiding with consistency, and displaying messages properly goes a long way. All those things are connected to blockchain design and UI/UX design generally. It’s a designers role to demonstrate these things. With blockchain apps, you have to signal to the user and say ‘hey, you’re fine, your assets are fine, everything is happening as it should.’ Grasping this proper flow is something that I strive for.

How do you get into the minds of everyday users — those who may not know, or really care about how something works, just that it works.

It’s always a matter of communication. You always have to listen to users and also the people you’re working with. Designing for blockchain is a collaborative process. You have to be an open, empathetic person. I have to think about different approaches to look at a problem from a different perspective. It depends on the project —  lots of our projects aren’t structured in a super strict flow.

There’s not always time for a lot of proper research. My role is to always try to understand the product as well as possible — try to pick through it in layers and from different angles of blockchain design. But my job doesn’t end there I also help guide in the implementation phase because I’m one of the few people, along with the product owner who knows the interface entirely.

I have to be a communicative person — I have to speak up with the product owner and present as many methods as possible based on the resources you already have. If there’s a space, I speak up and discuss with the users. If there’s time, I also map out a user story, write a backlog, and discuss it with developers. It’s a matter of constant discussion and analysis.

Which project that you’ve worked on are you the proudest of?

For sure Trade.io and CloseCross. For Trade.io there was already a web platform we didn’t build. Instead, we had to transform and migrate those functionalities and features to a mobile app. That was kind of challenging, however, the client was very helpful during the research part and they delivered a lot of already started wireframes and ideas for the UI. We didn’t build it from scratch but we built on top of something that already existed it was a super nice input at the very beginning that helped us to start from a good level.

With CloseCross, it was a project we helped design this platform in very close corporation with Vahibav Khadikar, the CEO. We had really long and intense sessions analyzing the UI in various versions — we did several versions. We had to think about the features, prototype it rapidly, verify the idea, and then build something on top of that.

CloseCross is a really large application with a lot of design features. As I said earlier, collaboration is something super important — it helps you to come up with really nice ideas and extend your possibilities because there’s no way one person could build something totally from scratch.

What are the main trends in blockchain design?

Trends in blockchain design are constantly changing — but the principles are the same. Design thinking, proper user research, quick evaluation of ideas like low fidelity wireframes. Those are essential tools that deliver really nice outcomes. Designing for blockchain involves trust-building features. The main trend is designing for the global nature of the blockchain — with proper localization and device agnostic.

You’d like to deliver your outcome and deliver the design you working on to as many people as possible so it’s super important also for trust to think about different languages and different devices. You have to design systems that work well across environments. 

Conclusion

Even though one blockchain technology’s greatest strengths is ensuring trust, Many users remain skeptical. Blockchain design is the most important challenge for widespread adoption. Cumbersome user experience will only hamper further adoption of blockchain among the wider public. Effective UX design is essential to create useful, valuable blockchain apps. designing for blockchain apps involves building trust through regular feedback and frictionless navigation.

Getting blockchain design right to make end users comfortable — and maybe not even notice the underlying tech, needs innovative solutions. Hajbos and designers like him are driving greater adoption of blockchain applications.

Categories
Software Technology

Client and Server Side Rendering Static Site Generators

Client and Server Side Rendering Static Site Generators

In the last few years the popularity of Single Page Applications has slightly increased. Before the SPA revolution, the majority of application logic was done back-side with some AJAX additions and the user interface improvements were done by JavaScript. Due to the fact that only a small piece of content was added asynchronously almost the whole content was rendered Server-side and available even while browsing without JavaScript.

When the SPA application appeared, in the era of Backbone JS, Ember and Angular, the first versions of all search engines crawlers were clear. None of them supported javascript rendering. Crawlers were just receiving the content rendered by servers and indexed by web pages which ended up with a terrible SEO so common while relying on javascript too much. Technology is evolving very fast, so a question arises whether the SEO problem is still valid for SPA applications in 2018/2019.

What is SSR? Do we need it?

SSR stands for Server-Side Rendering. It is a way to prerender parts of the application on the server like in a classical back-end language. A browser makes a request to a server, the server runs application pre-rendering, as it goes, and responds with a generated html. On the browser site the JS logic is automatically attached to the rendered state and the application can used as usual.
On the opposite end, we have Client-Side Rendering which is a standard method for all SPA frameworks. Such applications generate whole content in the browser runtime. Typically the client-side applications receive from the server a basic html structure with an empty placeholder “div” where all application components will be rendered.

There is also a third method similar to Server-Side Rendering called Static Site Generation. Although it may be confused with SSR, but the idea is a bit different. With this method during a building phase  html files are generated which will be served from the server. Such html files can be effective at rendering hundreds of components which will take time if done on client-side.The application can be pre-rendered once in a specific state, only to send it to the end user in simple html files in the fastest way possible while using http hosting.

We have 3 options to choose from. So, which one I should use?
Each option is used in specific cases and fulfils different needs. Let’s hope the following paragraphs will help you choose the best one.

Which solution I should use?

Client side rendering, server side rendering, static site generators

The infographic below shows a general idea behind each approach. The final effect is the same: fully functional application. The difference is in a way it is achieved.

At a first glance, all three graphics look almost the same with the same number of steps. The key difference is timing for each action. In client-side rendering, application stays long in the “loading” state, while it is making ajax request for necessary data, compiling views and injecting everything into DOM. Server load will be small even for a considerable number of requests. The browser side is overloaded with work which may even work longer and slower on weak computers or phones.

For server-side rendering most work is on the server-side, which does most of the job. The server executes the application code and generates html based on it in order to create a response.
After that the browser will need to attach all the events to the existing html, create virtual DOM etc. When does the server-side work the most? If the server is not powerful enough, the response time may increase slightly. With the server-side rendering we need to think how much traffic the application will generate and whether the server is able to handle it fast.

The third option is to use Static Site Generator which is the fastest one. The server just sends previously prepared html. On the browser side the framework that is being used is attached to the existing structure, as a result the application is ready to use. Neither the server nor the browser is excessively overloaded.

Let’s make a small comparison table for all the 3 solutions:

ProblemClient-Side renderingServer-Side RenderingStatic Site Generators
Social media sharing⛔??
SEO, search engines❓it’s complicated 🙂??
High traffic?⛔?
Frequently changed dynamic content??❓it depends
Easy to implement?⛔❓it depends

Quick notes about the above points:
In the case of social media sharing like Facebook or Twitter, they don’t execute javascript. With the client-side generated application there is always the same set of OG tags and meta properties, there is no possibility to share a specific page/route in our application/website. If social sharing is a must, then it is better to choose SSR or Static Site Generators.

SEO remains a big mystery. A few years ago the situation was clear because none of the the search engines  understood javascript. So, no content rendered client-side was indexed. The situation changed once Google announced that their crawler would finally render javascript. (The following paragraphs will contain small test to check them out). With SSR and Static Site Generators we are certain  that the content will be indexed, whereas in the case of CSR it’s a bit more complicated issue 🙂

For high traffic websites it is always  better to put as much as possible to the client, and CSR seems to be a reasonable option.

Static Site Generators don’t work well with a dynamic content because all html files are created much too often. Naturally, there can be parts which don’t change, to fully render the server-side and the dynamic ajax content on the client-side, in such a case Static Site Generators will do the job.

The easiest option to implement is a standard SPA app done client-side without any additions. With server-side rendering we have to maintain server part, which may be tricky based on solutions. With Static Site Generators depending on the chosen framework, the implementation will take as much as for client-side but with some additions.

How do crawlers work?

Crawlers are automated scripts which browse www to collect information about web pages and the connections between them. They are connected with search engines and pass on information to them. Based on the knowledge web crawlers/spiders collected search engines decide on the order in which search results appear.

Historically, no crawlers were executing javascript. Client-side rendered application was not indexed at all. The situation changed a little when Google announced that crawlers they were going to use execute javascript. It was great news but let’s remember there is world outside Google. And, there are more search engines on the market such as: Bing, Yahoo, Ask.com, Baidu, Yandex, DuckDuckGo and others.

According to market share calculations Google powered 76% of all searches. It means that 24% of searches around the web are done with different engines! How should we know how they will see our pages?  Here you can find fantastic tests with different frameworks and the most popular search engines. The results of this comparison are clear: only Google and Ask.com understand javascript and are able to index client-side rendered application correctly.

While creating a an application constantly ask yourself a question whether it is fine to be indexed only by Google and Ask.com or maybe it would be a good idea to consider other search engines on the market.

How will Google crawler see my page?

A while ago Google provided a great tool for developers in order to check how Google bots/crawlers can see our web pages. With just a few simple steps we can run a diagnostic of our page and see whether all information that is posted  is correctly rendered by the bot script. Bots may either reject some external scripts that are included or not render something if the execution time is too long. Unfortunately, there are no similar tools for other search engines and the developers learn about their functionality only from experiments like the one linked in the previous chapter.

Let’s test few simple examples using fetch as google tool. In the experiment we will check how Google render client-side rendered React application in different configurations.
Google needs to verify you as the owner of a webpage to be rendered by bot. There are multiple methods to achieve this. The simplest one requires uploading a file to the server or adding a special meta tag to the webpage.

Test 1 – a simple React application with nested components

Test 1 - a simple React application with nested components

The above example simple application with 2 nested components is being rendered by displaying image from an external link and a simple text. Everything is correctly rendered by Google bot. This proves that Google can handle correctly such a simple javascript rendered app.

Test 2 – a React application with a content loaded by slow AJAX response

Test 2 - a React application with a content loaded by slow AJAX response

In the above example there is an extended application from the previous example which adds a third component by requesting content from the server by using ajax request. The example adopted NASA api and it also added a small delay of 5-6 seconds for the content to be available the the application. When the content is ready both the image url and the simple text paragraph are rendered. Looks like again the bot has handled it correctly.

Test 3 – a React application with a very slow AJAX request

Test 3 - a React application with a very slow AJAX request

In the third example the first problem occurs 10 seconds have been added to the loading time for the AJAX response. The component is not rendered at all and it was skipped by Google bot. The example has used a single AJAX request with long loading time which probably would never happen in reality. But what about having a very complex application which has been created from hundreds of components and has relied on multiple external data endpoints? If there are some who require all Promises to be resolved then it is possible to end up with the same situation as the one above, some parts of the content will not be available for Google crawler and will not be indexed. In such a situation the only solution is to pre-render  SSR or Static Site Generators.

Summary

While developing a new Single Page Application we should carefully think over our needs. If we are going to implement an internal application, the admin panel where user needs to log in, we don’t need to worry about SEO, indexing or the social media stuff, client-side rendered application will do it for us.
Taking social media sharing into consideration use specific Open Graph tags for particular pages, having different titles and descriptions for each page etc. requires SRR or Static Site Generators. Social media tools don’t execute javascript so replacing meta information for specific routes will not be possible.

When we want to develop a website which should be indexed by search engines we need to be careful. If we only care about Google we can write client-side rendered application and in order to make sure that everything will be correctly indexed we should frequently check with fetch as google tool. Too long loading/rendering times may result in a part of the content not being indexed at all. If we need to support other search engines, the only solution will be to go for SSR or Static Site Generators solutions, because they are not prepared to oversee javascript applications.

While choosing between SSR and Static Site Generators we should consider how often our data will change. If we implement a highly static website we can choose one of the existing solutions for Static Site generators and develop our website in the technology we love to work with.

There are multiple libraries providing SSR and Static Site Generators solutions for top SPA frameworks. There are solutions for React, Vue or Angular. What are the differences and how to use them. Hope the lecture of my next article will help you choose proper tool for your next application.

See also: