The purpose of this project was to build an accessible website for Inclusive Web Solutions, an IT consulting company, The website consists of a public part, which presents the company, and a private admin site where employees can create, edit, update and delete the dynamic content of the site. Subscribers may only create, edit, update and delete their own blog posts. A REST API is used as a data source. All dynamic data is stored in a database. The website, the REST API and the database have been implemented using React, Node.js, Express.js, MongoDB and SASS. Web design, flowcharts and a target group analysis have been part of the planning phase. The website has been tested with regard to accessibility, responsiveness, compatibility and code validity using automated testing tools and user testing. The website was supposed to be accessible according to WCAG level AA. The website, the REST API and the database have been deployed. A custom domain has been added to the website. Överall, the purpose of the project has been achieved. There are a few issues with regard to the website’s responsiveness and accessibility. There are also a few usability issues related to the site’s multilingualism. The accessibility goal has not been fully achieved. Validation errors pertaining to the website’s HTML code can be explained by the validation method that was used. / Syftet med detta projekt har varit att skapa en tillgänglig webbplats a t konsultföretaget Inclusive Web Solutions. Webbplatsen består av en publik, tvåspråkig del som presenterar företaget, och en lösenordsskyddad administrationssida da r medarbetare kan skapa, redigera, uppdatera och radera webbplatsens dynamiska innehåll. Gästskribenter kan endast skapa, redigera, uppdatera och radera egna blogginlägg. Webbplatsen använder en REST-webbtjänst som datakälla och alla data som hanteras på den icke-publika webbplatsen lagras i en databas. React, Node.js, Express.js, MongoDB och SASS har använts för att implementera webbplatsen, REST-webbtjänsten och databasen. Arbetet har planerats med hjälp av webbdesign, målgruppsanalyser och flo desscheman. Webbplatsens tillgänglighet, responsivitet, kompatibilitet och validitet har testats med automatiska testverktyg och användartester. När det gäller tillgängligheten, sa har målet varit att uppfylla kraven på WCAG-nivån AA. Webbplatsen, REST-webbtjänsten och databasen har publicerats. Webbplatsen har dessutom publicerats under egen domän. Överlag har syftet med projektmålet uppnåtts. Alla delar har skapats och det mesta av funktionaliteten har implementerats enligt plan. Webbplatsen uppvisar vissa brister när det gäller responsivitet och tillgänglighet. Vissa brister i användbarheten finns, vilket rör bl.a. flerspråkigheten. Tillgänglighetsmålet har inte uppnåtts fullt ut. De valideringsfel som förekommer i HTML-koden har visat sig bero på hur valideringen har gjorts.

Over a few years back, REST APIs were considered standard web APIs, which nowhave a strong competitor. REST APIs provide some excellent features like stateless serversand structured access to resources. However, over time, it doesn’t offer flexibility withthe access of data and client changing requirements. In 2015 GraphQL was introduced byFacebook, which overcomes the problems with the REST and provides more flexibility andefficiency to the client requirements. For example, remove the over and under fetching.To change the existing APIs into GraphQL APIs require considerable time and effort.Therefore, some server implementation tools are developed to reduce the developmentcost and time. A few of these tools generate GraphQL schema and server implementationsautomatically over a legacy database.This master thesis studies tools that automatically generate GraphQL server implementationover legacy databases and evaluate such generated GraphQL server’s performance.First, we find some GraphQL server implementation tools such as Hasura andPostGraphile and then compare the server’s performance using benchmark methodology.Secondly, we run an experiment on a computer system and use the performance metricsfor assessment. The results of our experiment concluded that PostGraphile has higherthroughput and low query execution time as compared to Hasura. In most of the querytemplates from the benchmark, PostGraphile outperforms Hasura.