No abstract

GraphQL is a novel query language proposed by Facebook to implement Web-based APIs. In this paper, we present a practical study on migrating API clients to this new technology. First, we conduct a grey literature review to gain an in-depth understanding on the benefits and key characteristics normally associated to GraphQL by practitioners. After that, we assess such benefits in practice, by migrating seven systems to use GraphQL, instead of standard REST-based APIs. As our key result, we show that GraphQL can reduce the size of the JSON documents returned by REST APIs in 94% (in number of fields) and in 99% (in number of bytes), both median results.

Como quaisquer sistemas de software, frameworks e bibliotecas evoluem ao longo do tempo, assim como suas APIs. Consequentemente, sistemas clientes devem ser constantemente atualizados para utilizarem APIs melhoradas. Para facilitar essa tarefa e preservar a compatibilidade com versões anteriores, elementos de API devem ser depreciados com mensagens de substituição. No entanto, na prática, existem evidências de que esses elementos são usualmente depreciados sem tais mensagens. Nessa dissertação, são estudados um conjunto de questões relacionadas à adoção de mensagens de depreciação. O trabalho objetiva: (i) mensurar a utilização de mensagens de depreciação e (ii) investigar a necessidade de uma ferramenta para recomendar essas mensagens. Para tanto, foram verificados (i) a frequência de elementos depreciados com mensagens de depreciação, (ii) o impacto da evolução de software nessa frequência e (iii) as características dos sistemas com elementos depreciados corretamente. Para alcançar esses objetivos, foi realizado um estudo com 622 sistemas Java e 229 sistemas C#. Esse estudo mostrou que: (i) 66,7% dos elementos de APIs de um sistema são depreciados com mensagens de substituição em Java; para C# esse valor é 77,8%, (ii) em ambas linguagens há pouco esforço para melhorar as mensagens de depreciação ao longo do tempo e (iii) sistemas que depreciam elementos de API corretamente são estatisticamente diferentes em termos de tamanho, comunidade de desenvolvedores e atividade. Também foi realizado um segundo estudo para avaliar a viabilidade de uma ferramenta de recomendação capaz de inferir mensagens de substituição utilizando as soluções adotadas pelos desenvolvedores. Como resultado temos que: (i) 73% das recomendações sugeridas pela ferramenta correspondem de fato a mensagens de substituição reais de elementos de API depreciados e (ii) os percentuais de mensagens de substituição cobertos pela ferramenta em três sistemas relevantes são 28,2%, 30,7% e 37,5%. Os resultados obtidos apontam que essa ferramenta pode oferecer sugestões úteis para mantenedores de software.

No abstract

No abstract

This study compares the performance of the membrane bioreactor (MBR) inoculated with commercial baker's yeast (Saccharomyces cerevisiae) (MBRy) versus one inoculated with bacterial sludge (MBRb) for treatment of landfill leachate. The MBRb and MBRy were operated with a hydraulic retention time of 48 h, solids retention time of 60 d, and specific air demand based on membrane area of 0.6 m hm. The MBRy was more efficient in removing chemical oxygen demand (COD) (68 ± 12%), color (79 ± 8%), ammoniacal nitrogen (58 ± 18%), and phosphorus (62 ± 19%) compared to MBRb, which showed removal efficiencies of 44 ± 18%, 46 ± 20%, 45 ± 17%, and 29 ± 15% for COD, color, ammoniacal nitrogen, and phosphorus. Furthermore, the MBRy had lower production of soluble microbial products, which are the main cause of membrane fouling, and so a lower membrane fouling potential. The average hydraulic permeability of the MBRy (32.23 L m h bar) was about four times higher than that of the MBRb (8.34 L m h bar). Thus using commercial baker's yeasts as a MBR inoculum can enhance pollutants' removal and membrane performance.

Monorepos (Monolithic Repositories) are used by large companies, such as Google and Facebook, and by popular open-source projects, such as Babel and Ember. This study provides an overview on the definition and characteristics of monorepos as well as on their benefits and challenges. Thereupon, we conducted a multivocal literature review on mostly grey literature. Our findings are fourfold. First, monorepos are single repositories that contains multiple projects, related or unrelated, sharing the same dependencies. Second, centralization and standardization are some key characteristics. Third, the main benefits include simplified dependencies, coordination of cross-project changes, and easy refactoring. Fourth, code health, codebase complexity, and tooling investments for both development and execution are considered the main challenges.Regarding (i), monorepos are usually defined as a single repository that contains multiple projects related or unrelated, but there are two kinds of monorepos: "Monstrous" monorepos, which are commonly used by large companies, such as Google and Facebook, and Projects monorepos, which are used by medium-size open-source projects, such as React and Babel. Regarding (ii), the projects into a Monorepo share the same managing tools and the same version of dependencies, besides all projects are visible to contributors. Regarding (iii), benefits include simplified dependencies, better managing of crossproject changes, easy refactoring, simplified organization, improve overall work culture,

GraphQL is a novel query language for implementing service-based software architectures. The language is gaining momentum and it is now used by major software companies, such as Facebook and GitHub. However, we still lack empirical evidence on the real gains achieved by GraphQL, particularly in terms of the effort required to implement queries in this language. Therefore, in this paper we describe a controlled experiment with 22 students (10 undergraduate and 12 graduate), who were asked to implement eight queries for accessing a web service, using GraphQL and REST. Our results show that GraphQL requires less effort to implement remote service queries, when compared to REST (9 vs 6 minutes, median times). These gains increase when REST queries include more complex endpoints, with several parameters. Interestingly, GraphQL outperforms REST even among more experienced participants (as is the case of graduate students) and among participants with previous experience in REST, but no previous experience in GraphQL.